Re: Straw man variable stroke-width syntax proposal

Brian Birtles:

a)
> stroke-widths-array: <position>: <width>, <position>: <width> etc.

Yes, this is better understandable.
Why not to say, that the value of stroke-widths-array is a list of
parameter lists.
A parameter list starts with a '(' and ends with a ')' . 
(I think, there is no problem with parentheses , because we already have 
them for the transform list values. And it provides a readable type of 
grouping together everything for the same position.)
The list consists of a number for either the fraction (0 to 1 - you need no
%, therefore the better choice and we have already such fractions as for 
all opacity related properties and for keySplines) of the pathLength along 
the path or a point number or a length in user
coordinates as given by stroke-widths-position (instead of only
the keyword 'length' it might additionally or alternatively contain an 
unit identifier, if it is assumed to be helpful to use other units than 
user coordinates).
The following number represents the width at the position.
Another optional number is reserved for a later specification
of asymmetrical behaviour. Author may not add such an
additional number for SVG 2 documents.
Maybe later it could be defined, that if there are two numbers,
the first is for the 'left part', the second for the 'right part', if only
one number is provided, it is for both parts together. Doing it this way,
old SVG 2 documents will remain compatible with future versions.
If an SVG 2 viewer finds two numbers, but has not the capability
to present asymmetrical strokes, it simply adds both numbers
to one widths and does it symmetrically (this needs minor further
exploration, if negative widths to switch between left and right 
are possible as well).

d) Interpolation: 
    Well, if you note something like 
    stroke-widths-position: fraction;
    stroke-widths-array: (0, 20), (1, 50)
    one has to define somehow the widths 
    for all fractions between 0 and 1 ;o)
    Affine and discrete interpolations are mainly useful
    to create an advanced pattern - comparable to
    stroke-dasharray, but this can only provide binary
    pattern, either 0 width or finite width.
    Smooth interpolation is useful to get something
    more 'organic', for example to draw grass or 
    caulis of plants, but can be useful for smooth pattern
    as well, if you want to have no edges in the stroke
    presentation - obviously if an author has already managed
    to provide a path with no corners, typically there is some desire
    to have no corners in the stroke as well. 
    Somehow one has to realise the smooth 
    interpolation. If you use Catmull-Rom, this can be still
    have the effect of 'rounded corners', to be able to
    apply a second order smoothness or a more general
    behaviour, cubic interpolation is pretty useful, as for
    path data already available. 
    With Catmull-Rom for stroke authors can be forced
    to add much more points to the path d attribute to
    get approximately the intended smooth behaviour
    for the stroke, they already can realise for the path itself.

    I think, what you had in mind is interpolation between 
    property values for animation or transition - of course one
    has to take into account this as well. If we assume, that the
    list is a repeatable pattern and we have a list of property
    values with different list lengths, we simply repeat each 
    list until all cover the complete path. Between these extended 
    lists one can interpolate as usual, between each number of a
    list item separately.
    Because stroke-widths-array is considered to be a list of lists,
    one needs some more description for animation interpolation,
    but this is straight forward and less complex as for transform.
    Because stroke-widths-position defines the meaning of
    all positions in the list, it may only cause a surprise, if this
    property is animated. But this is more fun for authors, not really
    a problem for viewers.

    The shorthand notation stroke-widths may cause additional
    problems for animation, as a few other shorthand properties,
    in SVG only available as properties and not as attributes.
    Do we really need a shorthand notation causing such problems?


f) Structure of notations

>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!)

See suggestion above.
I see the advantage to put everything together to a list of lists, however
at some point, the complexity of the list becomes quite impressive.
For example if we want to add in this or a future version control points
for cubic interpolation, one gets something like:
stroke-widths-array is a list of parameter lists.
A parameter list starts with a '(' and ends with a ')' . 
The list consists of a number (for either the fraction of the pathLength 
along the path or a point number or a length as given by 
stroke-widths-position.
More numbers can follow, at least one.
If only one number follows, it represents the width at the position
It at least two numbers follow, the second represents the width
to the left, the third to the right.
There can be four more optional numbers, representing the
control points for cubic interpolation  ... (similar definition as
for keySplines list items).
At some points, one has to consider to provide even more
structure to such a list list item, maybe more parentheses or
markers to allow for example to skip the second width, but
to specify the control points etc.

g) See suggestion above, as long as authors are adviced not
to use additional numbers for SVG 2 documents, there should
be no problem for new viewers interpreting old documents.
And one can already indicate, that authors have to take into
account, that old SVG 2 viewers may only have a symmetrical
presentation.
Maybe we need a feature string switch or something like that,
to provide an option to switch between a tricky old or simple
stroke presentation for old SVG 2 viewers and future viewers.
Obviously one can avoid all this complications by specifying 
everything at once, we already know, that it will be useful anyway.
If in SVG 2 only symmetrical strokes are allowed, 
authors still can use masks and other advanced tricks or manually
calculated shapes, slowing down the rendering massively to get
the intended effect - once they can use different widths, there
will be the desire to have it asymmetrical, be sure ;o)  

h) I have seen the interesting caps - looks like a lot of
interesting fun, miters can be another interesting field of adventure
here, already for continuous interpolation, and for discrete one
gets similar problems as for stroke-dasharray, if the discrete
change happens near to a corner of the path - depending
on the accuracy of the viewer, the nightmare for authors starts ;o)
Because already the caps can get quite big, even for continuous
interpolation accuracy problems at miters may result in interesting
differences - from the point of a tester, more annoying from the
point of an author maybe - one has to look, how sensitive the
interpolation methods are for critical cases.


Olaf

Received on Monday, 13 May 2013 10:59:54 UTC