- From: Andreas Neumann <neumann@karto.baug.ethz.ch>
- Date: Wed, 12 Jul 2006 10:17:14 +0200
- To: "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de>
- CC: www-svg@w3.org
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