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-st...
2. 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.html
Minutes of last nights meeting: http://www.w3.org/2013/05/09-svg-minutes.html
Illustrator end-caps: http://lists.w3.org/Archives/Public/public-svg-wg/2013AprJun/0101.html
Here is a proposed syntax for variable width strokes:
http://lists.w3.org/Archives/Public/www-svg/2013May/0023.html
e) A path created using touch input
<path d="M123 345C...." stroke-widths-position="points" stroke-widths-array="1, 1.1, 1.15..." />
Sorry, a little bit OT
Is here any plan to link other values than the width of the stroke ? Why not the color of the stroke ?
Or the offset ? (I can't wait for http://w3-org.9356.n7.nabble.com/Feature-request-for-SVG2-stroke-position-td...)
GML (http://www.graffitimarkuplanguage.com/g-m-l-spec/) allows storing of more parameter from an input (like the tilt or zaxis value) could we store those values too and use them as a binding source for different stroke properties.
<path d="M123 345C...."
stroke-width:10px;
stroke-color:hsl(180,1,1);
array="pressure: 0.5, 1 ..."
array="tilt: 0.1, 0.9 ..."
array="z-axis: 0.5, 0.5 ... ">
<bind target="external-stroke-width, internal-stroke-width" source="pressure" />
<bind target="stroke-hue" source="tilt" min-hue="180" max-hue="360" />
<bind target="stroke-saturation" source="z-axis" min-hue="0" max-hue="1" />
</path>
this will draw a path starting with a width of 5px and a blue color then a width of 10px and a red color
2013/5/10 Tavmjong Bah <tavmjong@...8...>
Here is a proposed syntax for variable width strokes:
http://lists.w3.org/Archives/Public/www-svg/2013May/0023.html
Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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.
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.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
On 05/10/2013 06:49 PM, mathog wrote:
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.
If you convert a stroke with varying width to a path describing its outline right away you will not be able to edit the original stroke afterwards (but just the outline) because the inverse operation - guessing the variable width stroke from a path describing its outline - is between messy and impossible.
Storing both the outline and the original stroke is redundant.
The main application of variable width strokes are artistic drawings where you want to be able to edit the stroke in all its properties at any time.
I would guess that the computational load of the stroke calculation is neg- legible, especially when you place the support points of the outline at nodes. If there is any problem with that, a renderer could just cache the stroke outline.
Regards, Sebastian Götte
On Fri, 2013-05-10 at 19:27 +0200, Sebastian Götte wrote:
Storing both the outline and the original stroke is redundant.
I don't think it is in this case. The outline on-canvas clearly fulfills the display portion of expected svg output (ignore text for a second) while a stroke provides armature to edit.
What fun it would be to be able to add a defs path to any elements and control it like a puppet ;-) For this though, it's not outrageous to expect edit and view data to be saved.
Martin,
What fun it would be to be able to add a defs path to any elements and
control it like a puppet ;-)
I'd really like original path to be stored into defs rather than in inkscape:original-d so that you could apply multiple LPE (or multiple stroke) on the same base shape
On 11-5-2013 13:15, pennec victor wrote:
What fun it would be to be able to add a defs path to any elements and
control it like a puppet ;-)
I'd really like original path to be stored into defs rather than in inkscape:original-d so that you could apply multiple LPE (or multiple stroke) on the same base shape
Clone Original LPE enables this. http://wiki.inkscape.org/wiki/index.php/Release_notes/0.49#Clone_original
-Johan
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
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]
- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2013/5/10 Tavmjong Bah <tavmjong@...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:
This was not explicitly mentioned but I have 2 questions.
1. Will this 'variable stroke' feature be assigned a specific feature name to use with svg:switch?
2. Does the SVG WG consider implementing this as a vector effect rather than as a core property? Using a vector effect would be safer IMO, because if a bug or shortcoming is found in the mathematical specification of the effect, a new effect can be introduced in a later revision of the standard which has a different element name - this way legacy documents could still display the same while new documents could be authored with the improved effect. Moreover, I think it would be easier to provide fallbacks for viewers which wouldn't support this feature.
Regards, Krzysztof
On Fri, 2013-05-10 at 19:51 +0200, Krzysztof Kosiński wrote:
2013/5/10 Tavmjong Bah <tavmjong@...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:
This was not explicitly mentioned but I have 2 questions.
- Will this 'variable stroke' feature be assigned a specific feature
name to use with svg:switch?
I'll bring this up.
- Does the SVG WG consider implementing this as a vector effect
rather than as a core property? Using a vector effect would be safer IMO, because if a bug or shortcoming is found in the mathematical specification of the effect, a new effect can be introduced in a later revision of the standard which has a different element name - this way legacy documents could still display the same while new documents could be authored with the improved effect. Moreover, I think it would be easier to provide fallbacks for viewers which wouldn't support this feature.
You are probably right but I don't think this will get much traction.
The group seems to favor using a percentage of the stroke-width so that the natural fallback would be a stroke with that fixed width.
Tav
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
On Mon, May 13, 2013 at 4:59 PM, Johan Engelen <jbc.engelen@...2592...>wrote:
If you ask me: no percentage because "uneditable".
Only if by editing you mean traditional node-oriented path editing. For example a designer who prefers to tweak-tool paths, or just uses Simplify, couldn't care less about synchronizing the profile with path nodes.
On 14-5-2013 21:57, Dmitry Kirsanov wrote:
On Mon, May 13, 2013 at 4:59 PM, Johan Engelen <jbc.engelen@...2592...>wrote:
If you ask me: no percentage because "uneditable".
Only if by editing you mean traditional node-oriented path editing. For example a designer who prefers to tweak-tool paths, or just uses Simplify, couldn't care less about synchronizing the profile with path nodes.
Good point. Indeed the non-percentage thing has editing problems too. For example when deleting nodes, I did some trickery to not have all width nodes jump around... Delete/insert actions are instant and not repetitive like dragging something, so it seems to be ok to patch-up the location of the width knots just after deletion (in a before-after comparison kind of way). For a simplify operation, one can do a similar trick.
I do think that the user cares about synchronizing profile with the path itself, regardless of nodes indeed. For the percentage case, I believe just about any edit will require updating the position of the width nodes. For the non-percentage case, there are a bunch of operations that do not require updating (this is mostly how Powerstroke now operates).
Great that you joined in the discussion :-) Cheers, Johan
participants (8)
-
Dmitry Kirsanov -
Johan Engelen -
Krzysztof Kosiński -
Martin Owens -
mathog -
pennec victor -
Sebastian Götte -
Tavmjong Bah