I'm not sure this should be called stroke-widths.
See
http://www.inkscapeforum.com/viewtopic.php?f=22&t=14072

that extends the concept to "scale" multiple strokes at a time. So I called this stroke-scales.


2013/5/15 Tavmjong Bah <tavmjong@...8...>
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]
> > 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.

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




------------------------------------------------------------------------------
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