Two advantages of specifying this in SVG are that you can easily applyOn 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]
> > 1. 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.
the same stroke profile to multiple objects (e.g. hair) while keeping
the file size small and that you can animate it.
I agree that gradients along a path are desirable. It has been
> 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.
discussed.
Tav
------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...1794...s.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel