See FTS test 0622. In the XML <Path.Data> <PathGeometry> <PathFigure StartPoint="75,125"> <PolyLineSegment Points="100,200" IsStroked="true" /> <PolyLineSegment Points=" 125,125" IsStroked="false" /> <PolyLineSegment Points="150,125" IsStroked="true" /> <PolyLineSegment Points="150,200" IsStroked="false" /> <PolyLineSegment Points="200,150" IsStroked="true" /> <ArcSegment Point="250,125" Size="50,25" RotationAngle="30" IsLargeArc="false" SweepDirection="Clockwise" IsStroked="false" /> <ArcSegment Point="250,175" Size="50,25" RotationAngle="90" IsLargeArc="false" SweepDirection="Clockwise" IsStroked="true" /> <PolyLineSegment Points="200,230" /> </PathFigure> </PathGeometry> </Path.Data> The segments with IsStroked="false" should not be drawn. However the path position is computed as if they were. Care needs to be taken with regard to the end caps (flat caps should be drawn). Also, if the line has dashing, the dashing array should reset to the initial state upon a new IsStroked case. Beware of the case starting with IsStoked="false" and also note that the path could be closed or or not, with the first and/or last PolyLineSegment set to IsStroked="false". There is also a similar type of parameter IsFilled. That is tested in the CET tests but I don't believe it is in the FTS tests.
I've implemented so that GhostXPS will skip over path elements with IsStroked=false by doing a moveto to update the path position instead of drawing when we're computing a stroked path. This should reset the dash pattern. There's not much I can do about the line caps though, the ghostscript graphics library doesn't support separate linecaps on different parts of the path being stroked. Committed in revision 3055 and 3056.