Re: Variable width stroke proposal

Brian wrote:
> a) As you mentioned, it's more verbose. For some applications I think
this is significant.

Yes that's true.  My approach is not optimal for the common case where each
line profile is unique.


> b) It seems less amenable to stylesheet-based setting of sub-properties.
I actually don't know how critical this is, but I think being able to set
'stopUnits' to 'pathIndex' on a class of paths would be useful.

Hmm... That doesn't really sound to me like a common use case.


> c) It doesn't allow mixing stopUnits which was one of the criticisms of
my proposal[2] that I have just now fixed.[3]

We could use the same 'seg' approach in my pathIndex mode.


> d) It doesn't support absolute length-based indexing but that is probably
easily added.

That's what pathUnits="pathLength" mode is for.  Or am I misunderstanding?


> e) I don't think you want to overload the 'stroke' property

That was a typo.  I fixed that in a later post.  It should have read
stroke-width="url()".


Thanks for the feedback.

Paul








On 18 September 2013 19:42, Brian Birtles <bbirtles@mozilla.com> wrote:

> Hi Paul,
>
> Thanks very much for following this up. The alternative approach is much
> appreciated. This approach feels a little bit like the "super-path" syntax
> for SVG that has come up from time to time and carries with it some similar
> advantages, namely, it's easier to animate a single point, it's probably
> more amenable to binary representation and so on.
>
> A few things I'm not sure about:
>
> a) As you mentioned, it's more verbose. For some applications I think this
> is significant. I happen to have a vested interest in use case (d) in [1].
> In this use case where there is one stroke width value for every point in
> each path and stroke width lists are never shared, the strokeProfile syntax
> would be quite cumbersome to generate by script and increase the file-size
> significantly.
>
> b) It seems less amenable to stylesheet-based setting of sub-properties. I
> actually don't know how critical this is, but I think being able to set
> 'stopUnits' to 'pathIndex' on a class of paths would be useful.
>
> c) It doesn't allow mixing stopUnits which was one of the criticisms of my
> proposal[2] that I have just now fixed.[3]
>
> d) It doesn't support absolute length-based indexing but that is probably
> easily added.
>
> e) I don't think you want to overload the 'stroke' property here since
> that points to a paint server. I think the paint of the stroke should be
> able to be specified independently of its width. (And you still need a way
> to specify the base stroke-width for strokeUnits="strokeWidth".)
>
> I can see how this is more familiar to SVG 1.1 but I think we're trying to
> align more with CSS patterns these days. Element syntax is still a natural
> fit for many things (especially things involving hierarchies, or really
> complex things) but I'm not sure if it's the best fit here. But that's just
> my impression. What do you think?
>
> Best regards,
>
> Brian
>
>
> [1] http://www.w3.org/Graphics/**SVG/WG/wiki/Proposals/**
> Variable_width_stroke#Syntax_**examples<http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Variable_width_stroke#Syntax_examples>
> [2] http://www.w3.org/2013/06/03-**svg-minutes.html#item19<http://www.w3.org/2013/06/03-svg-minutes.html#item19>
> [3] http://www.w3.org/Graphics/**SVG/WG/wiki/Proposals/**
> Variable_width_stroke#Syntax_**proposal<http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Variable_width_stroke#Syntax_proposal>
>
>
> (2013/09/13 17:45), Paul LeBeau wrote:
>
>> I know Brian has been working on a proposal for variable width strokes.
>>   However I wanted to proprose a different approach that I think uses a
>> more familiar SVG style.  Hopefully this approach hasn't already been
>> suggeted and rejected.  A quick summary follows:
>>
>>
>> <?xml version="1.0"?>
>> <svg xmlns:xlink="http://www.w3.**org/1999/xlink<http://www.w3.org/1999/xlink>
>> "
>> xmlns="http://www.w3.org/2000/**svg <http://www.w3.org/2000/svg>"
>> version="1.1" width="450px"
>> height="450px" viewBox="0 0 450 450">
>>   <defs>
>>     <strokeProfile stopUnits="pathIndex" strokeUnits="userSpaceOnUse"
>> interpolationMethod="linear">
>>       <stop offset="0" stroke-width="4"/>
>>       <stop offset="2" stroke-width="32"/>
>>       <stop offset="4" stroke-width="16"/>
>>       <stop offset="5" stroke-width="10"/>
>>       <stop offset="6" stroke-width="24"/>
>>       <stop offset="8" stroke-width="4"/>
>>     </strokeProfile>
>>   </defs>
>>   <g fill="none" stroke="url(#swirl)">
>>     <path d="M 375,225 C 375,180 285,195 240,240 C 195,285 180,375
>> 225,375 C 270,375 255,285 210,240 C 165,195 75,180 75,225 C 75,270
>> 165,255 210,210 C 255,165 270,75 225,75 C 180,75 195,165 240,210 C
>> 285,255 375,270 375,225 Z" />
>>   </g>
>> </svg>
>>
>>
>> *stopUnits *can be one of "pathIndex" or "pathLength".
>>
>>
>> For "pathIndex", the stop offset value refers to the index of a
>> coordinate in the path or shape.  If there are more coordinates in the
>> path than stops defined, then the last offset is re-used.
>> For "pathLength", the stop offset value refers to a fraction of the path
>> length (0..1 or 0%..100%)
>>
>> *strokeUnits *can be one of "userSpaceOnUse" or "strokeWidth"
>>
>>
>> "userSpaceOnUse": absolute value in current userspace
>> "strokeWidth": a multiple of the currently defined stroke-width value
>>
>> *interpolationMethod *can be one of "linear" or "spline"
>>
>>
>> "linear": stroke width between stop offsets is linearly interpolated
>> "spline": a Catmull-Rom spline is used to interpolate between stop
>> offset widths
>>
>>
>> Another sample definition:
>>
>>     <strokeProfile id="swirl" stopUnits="pathLength"
>> strokeUnits="strokeWidth" interpolationMethod="spline">
>>       <stop offset="0" stroke-width="1"/>
>>       <stop offset="0.25" stroke-width="8"/>
>>       <stop offset="0.5" stroke-width="4"/>
>>       <stop offset="0.625" stroke-width="2.5"/>
>>       <stop offset="0.75" stroke-width="6"/>
>>       <stop offset="1.0" stroke-width="1"/>
>>     </strokeProfile>
>>
>> Any thoughts?  Does this approach have any merit?  I know it is a bit
>> more verbose than the style suggested by Brian.
>>
>> Paul
>>
>>
>>
>