Re: Straw man variable stroke-width syntax proposal

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

Received on Monday, 13 May 2013 02:01:24 UTC