Re: Straw man variable stroke-width syntax proposal

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?

And to be sure:
Such an offset is in the direction of the path progress
or perpendicular to this?

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.

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.

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)

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.

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.

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.

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)

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.

Because there are already ideas to define an offset perpendicular
to the path progress direction, ensure as well, that the behaviour
is here defined as well, because such offset-paths may result in
paths not representable with the current path commands like
cubic Bezier curves or elliptical arcs anymore, therefore it can be
mathematically interesting to apply such a variable width to
a path with a perpendicular offset. 
Once the option of asymmetry is considered, obviously one
could integrate such perpendicular offset as an asymmetry 
into this proposal to avoid such compatibility problems of
different new properties.



Olaf

Received on Friday, 10 May 2013 13:06:54 UTC