locked
Open path based custom strokes and undead filling RRS feed

  • Question

  • I'm seeing an odd behavior with custom strokes based on open figures, maybe is a already know fact since is not much changed from ED1 to the beta. Here it is:
    1) I create a custom stroke based on a curve and set its fill to none (filled strokes work correctly)
    2) I draw a figure (a rectangle and another curve in this sample) with that stroke
    3) I choose convert stroke to path.
    4) I try to fill the figures, you can see the results are far from what a filling will look on a similarly shaped figure drawn by hand.
    5) You can even modify with the lasso tool the ending of the "edge" of the filling to obtain half bordered creatures. Using the scissors is even more fun.
    6) Deleting with "delete anchor point" what was the starting point of the open path (or guessing right the position of a node on the dotted path) resurrects the undead fill to full life. It appears composed by dozens of anchor points.

    This is probably because Designer remembers where the filling of the original path (from which I drawn the stroke) was, so that if the user creates an open path with a filling, that filling will curve to follow the shape to which is applied. This is surely a good behavior that mirrors what a user will think would happen.
    But when the user decides to convert the stroke to a path, instead of this undead filling that refuse to behave, I would expect convert to not create anything else than the open path representing the line. It should remove any memory of the "potential" filling. Being its edge composed by really many points, with complex or multiple figures this could save resources.

    7) As things are now, the undead filling is exported also in XAML

    • Edited by Elena Malnati Saturday, April 5, 2008 10:52 PM changed to better describe problem
    Saturday, April 5, 2008 10:18 PM

Answers

  • Elena,

    The behavior your describe is not unusual. Remember, when you attack a stroke to a path and then choose to convert the stroke to a path, you are only converting the stroke to a path and not both the stroke and the object the stroke is attached to.
    Annie
    Sunday, April 6, 2008 9:33 PM
    Moderator

All replies

  • Hmm interesting!

    It might be worthwhile looking at the fill rules (Winding rule or Even-Odd rule unless these have been revised in ED2) to see what might happen.

    In general, I think skeletal strokes do have some peculiarities that may, on the face of it, seem a bit bothersome.

    However if experience is anything to go by then trying to tame skeletal strokes returns a much reduced and probably over compromised thing in its place.

    While the behaviour may appear to be odd it might still be better than a compromise?

    Any of the shapes could be retraced using pen/b-spline with stroke or no stroke and suitable fill?
    Sunday, April 6, 2008 3:27 PM
  • Elena,

    The behavior your describe is not unusual. Remember, when you attack a stroke to a path and then choose to convert the stroke to a path, you are only converting the stroke to a path and not both the stroke and the object the stroke is attached to.
    Annie
    Sunday, April 6, 2008 9:33 PM
    Moderator
  • Forgive me if I didn't answered to this for a while!
    About designer keeping the original object, I know this, but the rectangle you see in the example after the conversion is not the original object (it was transparent and looks like Designer killed it for this reason. I checked and there was no group, just the stroke).
    Anyhow, maybe this example is better: (XAML files here http://cid-2cc593ea7fc6b9d9.skydrive.live.com/self.aspx/designer/xaml1)

    A) the strokes, left one filled, right one no-fill.
    B) two yellow rectangles, one with the filled stroke, one with the no-fill stroke. Their XAML (Fill1.xaml and NoFill1.xaml) is identical (a part from the brush color)
    C) both of them with their strokes converted to path. I have ungrouped them and deleted the original yellow rectangle.
    The filled one is normal, the other seems just two lines, but if one clicks, that dashed line appears, that mimics the fill that is not there. This dashed part does not react normally to tools(scissors, yes;lasso,sometimes;delete node, only first node with fill applied). If you see their XAML now (Fill2.xaml and NoFill2.xaml), the filled one has a very clean XAML with far fewer nodes than before conversion, while the other has still many anchor points very close to each other. In XAML the dashed part appears bordered (XAML cannot represent a half bordered thing).
    So the things that seems "odd" to me with no-fill converted strokes are:
    * That dashed part that cannot be managed normally
    * One may end up having half bordered shapes that should not exists
    * The useful cleaning convert-to-path does by reducing the number of anchor points is not performed with no-fill strokes.
    To BBB: Until now I saw no impact of Winding/even-odd rules on this.
    Thursday, April 17, 2008 1:39 PM
  • Just returned from overseas so apologies if this seems a bit of guesswork for that really is mostly what it is.  

    The first thought is that images A seem to show ED is not too sure about what is the interior and what is the exterior for fill purposes.  I'd guess that fill is an interior thing as in "interior fill".  Having an open edge probably means ED is taking each stroke as a separate object.

    In E3 one could group separate lines to form an enclosed object using two options (real? logical?).  An additional consideration is the vector part of vector strokes.  So, for example, attempting to close strokes that have different directions can have different results according to where the first node was laid down.  The vectoring algorithms seem to take direction from first node to last node so two similar strokes might appear ok until closed.

    I expect far more learned contributors may have deeper insights but, again, it seems to be some of the conundrums associated with skeletal stroke based objects and how those elements work together.
    Sunday, April 27, 2008 8:25 PM