On Fri, 2013-05-10 at 09:49 -0700, mathog wrote:
On 09-May-2013 22:55, Tavmjong Bah wrote:
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:
[edited down to the list of questions]
- How should the position of the points where the widths are defined
be described along the path? 2. How should the widths be defined? 3. Should the widths be symmetric or asymmetric about the path? 4. Should negative numbers be allowed? 5. How should smoothing be done? 6. Questions about end-cap and line-join:
It strikes me that no matter how these questions are finally resolved the resulting construct is not likely to be very compatible with other graphics formats. There may be some graphics format that has a similar construct, but in the vast majority of cases the only way the resulting graphic could be represented is as a filled closed path. The questions above, where the answers in most instances are a matter of taste, suggest that it might be better to leave this feature out of SVG entirely and let programs which want to implement a varying width stroke do so with a filter or tool that converts from the initial fixed width stroke along a path to a filled object corresponding to the varying width stroke along the same path - the resulting object being just a normal collection of Bezier and linear segments. Among other advantages, the conversion which generates the new object only needs to be done once, rather than every time the object is moved on the screen, which would be the case if SVG supported this type (assuming it was handled like glyphs and other draw items are now, by the routines in src/display). Similarly, selection (by mouse) is already in place for the converted object, but looks as if it would be pretty messy for the varying width stroke object.
Two advantages of specifying this in SVG are that you can easily apply the same stroke profile to multiple objects (e.g. hair) while keeping the file size small and that you can animate it.
Also, to play devil's advocate, if the width may vary with position, why not also the color, transparency, and fill pattern? What makes the width "special"? Yes, width is the only one of these properties that does not require a sort of bitmap to be generated, but in terms of end user features, I suspect user definable color variance along the path might be in higher demand.
I agree that gradients along a path are desirable. It has been discussed.
Tav