Re: Rendering of stroke-dasharray in special situations

Hello,

>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).
>  
>
I agree that understanding it as a one-dimensional pattern is more 
useful. However, due to the problems of underlying rendering engines and 
CPU limitations we cannot fully enforce the behavior of the 
stroke-dasharray as a one-dimensional pattern. See notes below.

>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.
>  
>
We added this informative note:

Note: Certain cases regarding the behavior of stroke-dasharray are not 
fully specified because SVG Tiny implementations often rely on 
underlying graphics libraries with predetermined behaviors they cannot 
easily change. Examples include: rendering of stroke-linejoin and 
stroke-linecap in case a dash ends exactly at a corner of two path 
segments, continuation of stroke-dasharray in subpaths, and others. 
These cases may be fully specified in version SVG 1.2 Full. Additional 
attributes, such as dash-caps that can be defined separately from 
linecaps may be added. Authors are encouraged not to rely on a specific 
behavior of a specific viewer for stroke-dasharray regarding these 
currently unspecified cases.

>>>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.
>  
>
see informative note above. We will deal with this in SVG 1.2 full and 
already raised an issue about this.

>>>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.
>  
>
The addition now reads as follows:
---------
The computed value of the attribute stroke-linecap is applied to both 
sides of each dash. If a dash has zero length, linecaps are still added 
if the stroke-linecap values round and square are used.
---------

You are right, there are still some special ambiguous cases where we 
violate the one-dimensional pattern rule. We will deal with these 
exceptions in the full profile.

Andreas

-- 
----------------------------------------------
Andreas Neumann
Institute of Cartography
ETH Zurich
Wolfgang-Paulistrasse 15
CH-8093  Zurich, Switzerland

Phone: ++41-44-633 3031, Fax: ++41-44-633 1153
e-mail: neumann@karto.baug.ethz.ch
www: http://www.carto.net/neumann/
SVG.Open: http://www.svgopen.org/
Carto.net: http://www.carto.net/

Received on Wednesday, 12 July 2006 08:17:32 UTC