Hi!
Maybe you find interesting how Synfig implements the variable width along a path.
Initially Synfig tied the width controls to the stroke points so you can vary the width from control point to control point of the stroke. This is useful in many cases but produces problems for those cases where the stroke has many points and the wanted width variation is smooth from the start of the stroke to the end.
Also, when the number of control points is small and you want to have many control widths you become forced to add more unwanted control points to add variable width there.
So we came in with the Advanced Outline:
http://wiki.synfig.org/wiki/Advanced_Outline_Layer
The advanced outline responds to those questions this way:
1. How should the position of the points where the widths are defined be
described along the path?
It has two options.
a) Homogeneous: position of the width control is total length stroke based.
b) Non Homogeneous: position of the width control is based on the number of beziers and inside each bezier it is length based. So for three beziers (4 points if the stroke is open) a position of 0.5 means the middle length of the second bezier. But for four beziers (5 points if the stroke is open) a position of 0.5 means coincidence with the third control point of the stroke
(regardless the length of each bezier)
2. How should the widths be defined?
We use a multiplier of the global width of the stroke. A value of 1.0 (neutral multiplier) will use the global width of the stroke. Negative values are allowed.
3. Should the widths be symmetric or asymmetric about the path?
We use symmetric. It is easy to extend to asymmetric.
4. Should negative numbers be allowed?
Yes
5. How should smoothing be done?
We use a 5th degree spline smooth function in linear combination with a linear interpolation. An extra parameter (smoothness) allows to change between full smooth to linear. Details here:
https://github.com/synfig/synfig/blob/master/synfig-core/src/synfig/valuenode_wplist.cpp#L107
6. Questions about end-cap and line-join
We have discontinuities in the tangent depending on the interpolation smoothness value. When interpolation is full smooth its tangent is continuous. When interpolation is linear, tangent is not
continuous.
One latest addition non mentioned in the wiki yet, is the inclusion of a internal parameter of the width control: lower and upper boundaries.
Those values (default lower=0.0 and default upper=1.0) defines how is the width control placed along the stroke.
This solution was applied when we found that the width control points moved when you extend a stroke in drawing mode. Extending the stroke implies in the worst case to increase the number of bezier points and/or the overall length of the stroke. In those cases it is impossible to keep the width control points in place, so we added the lower and upper boundaries to adjust those values when the stroke is extended to keep the width control points in place form the point of view of the old stroke (before extend). So when you extend a stroke, the width control points boundaries are modified from the defaults to the calculated values to keep them in place. For example, one width control point that is placed at a position of 0.5
from the point of view of the original stroke (at its middle of a 0.0 to 1.0 boundaires), when the stroke length is doubled, the width control point position doesn't change (it remains to be 0.5) but the boundaries goes from (0.0, 1.0) to (0.0, 2.0).
This is very important when you deal with device inputs where the user doesn't create the stroke in one time, but in several and consecutive hand drawn strokes that are joined together in a single object.
Maybe you wonder why do we want to have a single object after the extension of the stroke: keeping one single object allows to animate the width control position along all the extended stroke without troubles, and at the same time it keeps the width control position in place after extend.
Finally, Advanced Outlines supports dashes with custom tips for each side of the dash segment and variable width within the dash segment length.
I hope those comments helps you to decide about Powerstroke and to give suggestions to SVG Working Group.
Cheers!
Date: Fri, 10 May 2013 07:55:03 +0200
From: Tavmjong Bah <
tavmjong@...8...>
Subject: [Inkscape-devel] [SVG WG] Variable width strokes
To:
inkscape-devel@lists.sourceforge.netMessage-ID: <
1368165303.2239.145.camel@...16...>
Content-Type: text/plain; charset="UTF-8"
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:
1. 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 WG seems to favor defining the position using a property via the
distance 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-stroke-eg.png2. 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.
3. 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.
4. Should negative numbers be allowed?
PS allows negative numbers. The WG seems to favor allowing negative
strokes if asymmetric strokes are allowed.
5. 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.
6. 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).
Tav
Discussion on www-svg:
http://lists.w3.org/Archives/Public/www-svg/2013May/0002.htmlMinutes of last nights meeting:
http://www.w3.org/2013/05/09-svg-minutes.htmlIllustrator end-caps:
http://lists.w3.org/Archives/Public/public-svg-wg/2013AprJun/0101.html