Re: Straw man variable stroke-width syntax proposal

Hi!

You should also make sure that the variable stroke width properties can be
animated. Splitting the values and positions is good for that:

>  stroke-widths-values: 0.1, 1.1, 0.3;
>  stroke-widths-positions: 0%, 70%, 100%;
>
> And the shorthand would become:
>
>  stroke-widths: 0.1, 1.1, 0.3 @ 0%, 70% 100%

Animation would look like this:

<animate begin="0" dur="4" attributeName="stroke-widths-values"
keyTimes="0;0.5;1" values="0.1, 1.1, 0.3 ; 0.4, 1.4, 0.4 ; 0.1, 1.1, 0.3"/>
<animate begin="0" dur="4" attributeName="stroke-widths-positions"
keyTimes="0;0.5;1" values="0%, 70%, 100% ; 0%, 50%, 100% ; 0%, 30%, 100%"/>

In above example, the line gets thicker and then thinner, while the
thickest point is moved towards the start of the path.

Cheers,
Kari



2013/5/13 Brian Birtles <bbirtles@mozilla.com>

> Dear Dr. Hoffmann,
>
> Thank you very much with your feedback! I think you have raised some very
> good points.
>
> (2013/05/10 22:06), Dr. Olaf Hoffmann wrote:
>
>> Hello,
>>
>> a) Just for understanding, 'offset' means something
>> that corresponds to stroke-dashoffset? This means
>> an offset into the width pattern list to start the width variation
>> or an offset according to a fraction of the path length,
>> the width variation starts at?
>> Do negative offsets have the opposite effect?
>>
>
> Sorry, this naming is confusing. The 'offset' here is really the
> _position_ along the path where the stroke width value should be applied.
>
> So the proposal is:
>
>   stroke-widths-array: <position>: <width>, <position>: <width> etc.
>
> (Having said that, something like stroke-dashoffset may be useful.)
>
>  And to be sure:
>> Such an offset is in the direction of the path progress
>> or perpendicular to this?
>>
>
> The position is in the direction of the path progress.
>
>  A simple SVG sample document with straight lines
>> simulating the effect with and without variable stroke-width
>> could be useful to get the ideas right.
>>
>
> Yes, I agree. I would like to see if there is other feedback first before
> I write up something more concrete.
>
>
>  b) Continuation of the width pattern from subpath to
>> the next subpath should be noted explictly - this is still
>> confused in many viewers for example for stroke-dasharray,
>> causing lots of problems for authors getting the intended
>> behaviour, if a path consists of more than one subpath.
>>
>
> Yes, definitely.
>
>
>  c) about:
>> "'3.2' is a point 20% along
>> the 4th segment in the path"
>> - does this mean 20% according to the
>> path length of the segment?
>> Or 20% according to some parametrisation
>> of the segment (was is typically simpler, but
>> less useful)
>>
>
> I agree, 20% according to segment length seems more useful. I believe this
> is what Inkscape does but Tav can confirm or clarify this.
>
>
>  d) I think, it is not mentioned, how to interpolate between the
>> given values of such as widths list - could be discrete, affine or
>> smooth.
>> Cubic would be another pretty more useful option, but requires
>> control points as for animateMotion as already suggested.
>>
>
> That's a good question and something I haven't thought about.
>
> I imagine interpolating between lists with the same number of elements and
> same position-type using linear interpolation would be useful and
> straightforward. It is also similar to what we do when interpolating path
> data and CSS gradients. Do you have specific examples of cases where other
> types of interpolation would be useful?
>
>
>  e) It should be possible as well to have a notation, that allows
>> discrete switches of the width at certain points and else
>> continuous behaviour - comparable to the situation in
>> animation: If in a keyTimes list two list items have the same
>> time and the corresponding values in the values
>> list are different, one gets effectively a discrete jump.
>> I cannot see, how to get this here - could be very interesting
>> to get nice pattern, one else has to realise it with some
>> advanced combinations of different decorated copies
>> of the same path with different width pattern combined
>> with stroke-dasharray etc.
>>
>
> Yes, I agree. I think we should ensure that the behaviour when specifying
> two or more widths at the same position is well-defined and produces a
> discrete jump.
>
> Since I'm proposing that the list be ordered, from a parsing point of view
> I think this should be ok.
>
>
>  f) The structure of the stroke-widths-array looks quite complex
>> for authors and the usage of ':' looks unusual.
>> Maybe better to separate this in two properties/attributes,
>> one with the [<percentage>|<length>|<**number>] offset part
>> and one part with the list of numbers, this might result in
>> something similar as already defined for stroke-dasharray.
>>
>
> Yes, I agree the ':' is unusual, particularly when it is used in CSS to
> separate the property and value. At the same time I prefer to avoid a list
> of numbers whose relationship is not obvious. (CSS box-shadow is absolutely
> horrible in this way!)
>
> Perhaps reversing the order of the arguments and using '@'?
>
> e.g. stroke-widths: 0.1, 1.1 @ 70%, 0.3;
>
> (Or perhaps → (U+2192), e.g. stroke-widths: 0.1, 70% → 1.1, 0.3  ;) )
>
>
> I'm somewhat uncomfortable with splitting it out like <animate> does
> (keyTimes/keySplines etc.). I find these parallel arrays hard to work with
> and hard to read. Maybe it's ok though? The above example would become:
>
>   stroke-widths-values: 0.1, 1.1, 0.3;
>   stroke-widths-positions: 0%, 70%, 100%;
>
> And the shorthand would become:
>
>   stroke-widths: 0.1, 1.1, 0.3 @ 0%, 70% 100%
>
> Or something like that?
>
> Actually, that's not so bad after all. I'm starting to like it :)
>
>
>  g) And obviously it would be fine to reserve already a notation
>> for asymmetrical widths, even if this is not intented for
>> the SVG version discussed here.
>> Else one has to introduce a complete new
>> property/attribute, if asymmetry is defined in later versions, to
>> allow backwards compatibility for older viewers.
>> To avoid such complications in the future, I still think, it is better
>> to specify everything now and at once.
>> As can be seen with stroke-dasharray, such retarded approaches
>> result in endless complications and suboptimal implementations -
>> still after more than 10 years effectively stroke-dasharray is not
>> really usable by authors for arbitrary path data ;o)
>>
>
> Yes, I agree, it's useful to think about the asymmetrical syntax in
> advance and take steps to ensure it's easy to introduce later.
>
> In a sense it might be better to *not* spec the asymmetrical syntax though.
>
> Consider this scenario (a):
>
> 1. We spec the '<number>[/<number>]?' syntax and say that UAs must ignore
> the second number
> 2. A future version of SVG defines asymmetric strokes and uses the second
> number.
> 3. Legacy UAs rendering newer SVG content will apply the stroke-width for
> the left-hand side of the stroke symmetrically which is not likely to
> produce a good result.
>
> Alternatively, scenario (b):
>
> 1. We define strict processing of 'stroke-widths-values' so that the
> entire property is ignored if anything does not fit the grammar.
> 2. A future version of SVG introduces the '<number>[/<number>]?' syntax
> and defines how to render asymmetric strokes.
> 3. Authors can then write the following CSS:
>
>   stroke-widths-values: 1.1, 1.3, 0.5; /* For SVG2 UAs */
>   stroke-widths-values: 0.8/1.4, 1.2/1.4, 0.3/0.65; /* For SVG3 UAs */
>
> What do you think?
>
>
>  h) Analyse, if there appear conflicts with other stroke-properties,
>> for example miters and caps.
>> Non trivial examples are required to see, if some degenerate
>> notation cases result in a meaningful or at least defined behaviour.
>>
>
> Yes, we definitely need to look into this and this came up in the telcon
> last week. I've just been thinking about the syntax but of course this
> can't be separated entirely from the rendering behaviour. I think Rik may
> have ideas about specifying the rendering behaviour?
>
>
> Thank you once again Olaf!
>
> Best regards,
>
> Brian
>
>