Hi Tav, I'll reply inline from my experience programming the PowerStroke LPE. (ah! halfway writing the reply I figured out that PS means PowerStroke, and not PhotoShop, haha :)
On 10-5-2013 7:55, Tavmjong Bah wrote:
Hi Johan and others,
The SVG Working Group discussed variable width strokes last night. A number of questions came about how it should be implemented in SVG. As we have this implemented via the Power Stroke (PS) LPE it would be interesting to get some feedback from Johan and others about these topics:
- How should the position of the points where the widths are defined be
described along the path?
PS uses a real number where the integer part gives the node (numbered from the start of the path) and the fractional part the fractional distance between that node and the next node.
The fractional part is not the distance between nodes. It is the 'time' value of the bezier segment between nodes. Getting the proper length/distance along a bezier segment is non-trivial, and calculation intensive (or so I've been lead to believe ;).
The WG seems to favor defining the position using a property via thedistance along the path defined either as a percentage of the total length or in absolute units. The argument is that then the same property could be assigned using CSS to multiple paths (e.g. a large number of lines that represent hair). On the other hand, having node based positioning would allow a use as shown in:
https://people.mozilla.com/~bbirtles/variable-width-stroke/variable-width-st...
I guess there are advantages both ways. Percentage-wise has the issue of arclength calculation I mentioned above. Performance-wise, when only part of a long path is visible, the node based positioning is much easier to handle, while the percentage-wise thing will still require calculation of distance along the full path length. I don't know if this argument is at all relevant, but may be something to keep in mind. Within Inkscape, the percentage thing gets annoying either for the coder or for the artist. If sane coder -> changing one segment changes distance along the path and all nodes shift -> insane artist. For a sane artists -> while changing segments e.g. by dragging control knots also recalculate new distance positions of each width knot and update percentages -> really insane coder. Inkscape already does some similar magic for the artist when adding a node in the middle of the path. Adding to a path sometimes works, sometimes completely changes the result... If you ask me: no percentage because "uneditable".
How should the widths be defined?
PS uses absolute user units. The WG seems to favor using a percentage of the stroke width. This would allow quick adjustment of the whole path thickness.
PowerStroke defines it in px units, because stroke width of the path is really no option for the LPE (the stroke defines something else after the LPE, try it). The percentage of stroke width seems reasonable; the fact that PS cannot use it does not matter for the SVG definition.
Should the widths be symmetric or asymmetric about the path?
PS uses symmetric widths. The WG wants to eventually allow asymmetric strokes but maybe not at the time.
I think many people want asymmetric width, and I think it is not too hard to realize that for PS. With the restriction that the widths for left and right part of the stroke are defined on the same knots (so each knot carries 2 widths, instead of having separate knots for left and right).
Should negative numbers be allowed?
PS allows negative numbers. The WG seems to favor allowing negative
strokes if asymmetric strokes are allowed.
Besides tricky coding for joins (which curve is on the inside, which on the outside) allowing negative width seems trivial and gives nice results. I remember having 'fun' on getting all cases right with joins, but I believe I got it working.
How should smoothing be done?
PS provides four different algorithms. The WG seems to favor for the
moment one smoothing algorithm (Catmull-Rom?) with maybe a linear smoothing. There was some discussion of allowing the algorithm to change along the path.
Allowing change of algorithm (linear <-> smooth) is very powerful and much desired I feel. I'm thinking about something that behaves similar to how spiro curves work. Could be done by including smoothness type for each width point:
c 0, 10px --> curved c 1, 20px ] 2, 10px --> left of node curved, linear on right s 2.5, 15px --> linear [ 3, 10px --> right of node curved, linear on left c 4, 20px c 5, 10px
Questions about end-cap and line-join:
PS has discontinuities with the various end-caps. Illustrator has
continuous edges (at least with round end-caps).
This is simply an oversight; I was surprised rereading 'PS' as 'PowerStroke', and had forgotten this still needed work. I think I stopped working on it after I got the joins working reasonably. Fixing cap continuity should be straightforward from there and should behave the same as join caps. The current behavior makes no sense to me.
Ciao, Johan