Re: Rendering of stroke-dasharray in special situations

Hello,

> Dear Olaf Hoffmann,
>
> Thank you for your useful feedback on stroke-dash issues. First let us
> clarify that the WG sees stroke-dashing only as a pattern or sequence of
> dashes and gaps. Pattern not in a sense of the pattern
> feature present in the SVG 1.1 full profile.

Well, I never thought, that this is the same as the two-dimensional pattern,
pattern are not aligned along the stroke even if applied to the stroke of a
path. 
If SVG1.2 does not define it anymore as a pattern of dashes and gaps, most 
of these issues are no problem anymore as already mentioned
(independent on the fact that stroke-dasharray will be more useful if defined
as a one-dimensional pattern).
Anyway it was not my intention to get a change in SVG1.2 mobile.
But even 'a pattern or sequence of dashes and gaps' generates the 
same problem/interpretation as a pattern aligned along the stroke. 
Only the word 'pattern' already implies  some interpretation as a
one-dimensional pattern and not as a simplification to generate subpaths
(just for stroking).

> >
> > 1. Rendering of subpaths
> > Should the stroke-dasharray pattern restart with the
> > initial value of the pattern with the beginning of a
> > subpath or should it continue with the pattern?
>> ...
>
> The working group discussed this issue and found it worthwile specifying
> it in a future version of the full profile but doesn't want to dictate a
> behaviour in SVG 1.2  tiny. The reason is that viewer implementations
> often don't handle stroke-dashing themselvers but pass the path geometry
> to the underlying rendering library which handles the stroke-dashing. It
> would not be feasible for constrained mobile devices to split paths into
> subpaths for full control of the dashing behaviour.
>
> We added wording to the specification, however, to recommend an SVG Tiny
> 1.2 implementation to restart the stroke-dashoffset from scratch for
> each path segment taking into account the initial stroke-dashoffset
> value, with a note that SVG 1.2 Full might be stricter on this issue.
> This is a currently a should and not a must.
>

That is pretty good for the SVG Tiny 1.2, because authors are now informed,
that the behaviour is not specified or reliable in this situation with SVG
Tiny 1.2 (and with previous specifications). This should be enough to 
avoid disappointments about different presentations in different viewers
or viewer versions.

> > 2. Definition of intervals for dashes and gaps
> > If we have stroke-dasharray="800,200"
> > belongs 800 to the dash or to the gap?
> > This is getting important for stroke-dashoffset
> > for paths with subpaths and for paths with edges
> > and corners and for animation.
> > I think it is useful to define this similar as for time
> > intervals  in animation, this means in this example
> > 0 belongs to a dash, 800 to a gap, 1000 to a dash
> > and so on.
>
> The specification states: "'stroke-dasharray' specifies the pattern of
> dashes and gaps that shall be used to stroke paths. <dasharray> contains
> a list of comma-separated (with optional white space) <length>s that
> specify the lengths of alternating dashes and gaps that must be used."
>
> This clearly states that an implementation must start with a dash and
> continue with a gap. We think that the specification is clear enough and
> that we don't need any additional wording. Additionally, the existing
> implementations all handle this stroke-dash behaviour consistently.
>

Hmmm - the problem was not the inner part of the interval, I agree,
this is pretty clear. What I mean is just the border between a dash
and a gap. In stroke-dasharray="800,200" it is just the question if
800 itself either belongs to the dash or to the gap, it can't belong 
to the dash and the gap, just to one of them. Often this is not 
important, but for example if 800 is exactly the position to apply a
stroke-linejoin, this can decide, if the complete edge of the path is 
painted or not.
Again, if SVG Tiny 1.2 informs the authors, that behaviour of 
stroke-linejoin combined with stroke-dasharray is not specified yet,
this is ok already for this point. And maybe it is enough for the
full profile to define this combination more specific as to define
exactly the borders of the intervals.
Up to now, I cannot see further problems with animations for
this, the reason for the mentioned fear about this was only
a bug in one viewer as I discovered now (and I still have to
report ;o) Maybe it is just the careful and clean way to define
it, just to avoid questions and problems, not detected yet.

> > 3. Rendering of stroke-linecap
> > The stroke-dasharray section defines dasharray as a
> > pattern of dashes and gaps (therefore the dashes
> > are no subpaths).
> > Should the pattern continued forward and backward
> > into the linecaps or should the stroke-linecap have the
> > same behaviour as the related point of the stroke?
> > ...
>
> The working group believes that "dash-caps" should currently behave like
> "linecaps" at the end of lines or paths.  It is however, true that this
> behaviour is not yet exactly specified. This also implies that the
> sequence of dashes and gaps does not apply for the "dash-caps".
>
> We added the following sentence to the definition of the
> stroke-dasharray attribute to clarify the behaviour:
>
> "The computed value of the attribute 'stroke-linecap' shall be applied
> to each dash when the attribute 'stroke-dasharray' is set to a value
> other than 'none'."

Yes, as mentioned already, this avoids confusion for 
SVG Tiny 1.2 as the simplest solution, but will result 
in caps painted outside of a curved path itself, no
problem at all, if specified.

>
> > <path d="M100,100 L100,100"
> >    stroke="#00f" fill="none"
> >    stroke-width="160"
> >    stroke-dasharray="40,40"
> >    stroke-linecap="round" />
> > (or with d="M100,100 z", both in
> > combination with stroke-dasharray more
> > useful as a subpath, not as a complete path
> > of course).
> > For this special case either the stroke-dasharray
> > should be ignored or the value of  stroke-dasharray
> > pattern at the position in the subpath should be
> > used. Alternatively a radial pattern might be useful,
> > using circular dashes. Then a starting position for
> > the pattern has to be defined, either at r=0 or at
> > r=stroke-width/2.
>
> The spec already clarifies this behaviour in the definition of the
> "stroke" attribute:
>
> "A subpath (see Paths) consisting of a single moveto shall not be
> stroked. A subpath consisting of a moveto and lineto to the same exact
> location or a subpath consisting of a moveto and a closepath shall not
> be stroked if the 'stroke-linecap' property has a value of butt and
> shall be stroked if the 'stroke-linecap' property has a value of round
> or square, producing respectively a circle or a square centered at the
> given point."
>

This is pretty clear, and this problem only occurs, if the stroke-dasharray
is interpreted as a pattern as defined in previous specifications.
If caps have to be painted around the dash, it will never happen, that
some visual part has a smaller structure than the cap, therefore no
structure has to be defined for zero length subpaths. stroke-dasharray
can never be inside the caps, if they are always added to the dash.

> Note that the working draft currently available to the public reads
> slightly different in that we did not specify what happens in the case
> of "square" linecaps. This is now addressed in the most recent working
> draft as written above.
>

I think, in previous specification it was just for round caps.
I noticed already a rule for 'square' in appendix C.6


> > 4. Rendering of stroke-linejoin (especially miter)
> > If the path is not continuously differentiable
> > (normally this means, there is a corner) at a
> > point with a border between a dash and a gap,
> > how should the stroke-linejoin be rendered?
> > If we use the interval definition from 2, the
> > behaviour of the pattern can be applied to the
> > stroke-linejoin. Or should the stroke-linejoin
> > be divided along the bisecting line half with a
> > dash and half with a gap? Or should the
> > stroke-dasharray be continued in the direction
> > of the bisecting line?
> > A detailed definition is especially useful for
> > animation.
> > And some examples for such an area with
> > a border between a dash and a gap near such
> > a corner might be very helpful for developers
> > and authors to understand, how such corners
> > have to look with different values for stroke-with
> > and stroke-dasharray.
>
> Good point. The working group discussed this issue. Most SVG tiny
> implementors can't control the behavior of the rendering library in this
> case, though. Therefore we decided not to dictate a behavior and revisit
> this issue when working on SVG 1.2 full.

It is helpful again to point out for authors, that behaviour in this
situation in SVG 1.2 tiny (and previous specifications) is not specified 
yet, just to avoid searching in the specifications, guessing and 
needless bug reports to implementors ;o) 

Best wishes

Received on Tuesday, 27 June 2006 16:41:05 UTC