Re: zero length dashes

Rik Cabanier:

>When a dash is of length 0, its end caps are supposed to be drawn along the
>direction of the original path.
>Maybe what the SVG spec should do is:
>- defined the concept of an original subpath which is the path before it is
>divided into subpaths before the dash array is defined
>- update the section that describes drawing the end caps so it refers to
>this new concept.
>ie
>
>its longer edges, A and B, are parallel to the line perpendicular to the
>*original* subpath at distance position along it.

You should not mixup the concept of a subpath (fragment of the value
of the path d attribute starting with a command M/m) and dashes and
gaps of the stroke-dasharray property.
I think, because several people mix this up, the feature  stroke-dasharray
is often corrupted in several implementations somehow,  leaking already
into the SVG 2 draft at some points.
stroke-dasharray is no method to create new subpaths, it is only a method
to provide a pattern for a stroke.

SVG defines the direction of subpath of length zero in the implementation
notes. Therefore even for them there should be always a direction for the
stroke-dasharray as well.
If only a dash or gap has length zero, this has no influence on the direction
of the path it belongs to, therefore no problem to align it.

More problematic, but somehow related to the problem, that dashes are
mixed up with subpaths is, that there seems to be still no feature to control
the 'caps' of such dashes or gaps in the SVG 2 draft as promised in 
SVG 1.1.2 and SVG tiny 1.2, this is annoying for authors really wanting 
to use stroke-dasharray as a pattern along the stroke.
This is strongly related to the problem, that it is often of limited or no 
use, that the caps from stroke-linecap are applied to dashes at all, 
especially if the stroke-width is larger than the dash or gap length.
The current behaviour to always apply the stroke-linecap to dashes
is a serious limitation of the usefulness of stroke-dasharray at all.

Another problematic issue with the current draft text:
'The resulting even-length dashing pattern is repeated along each subpath. The 
dashing pattern is reset and begins again at the start of each subpath.'
This is in conflict with the definition of M/m commands and causes problems
and a lot of work for animations of the property (one has to devide paths with
subpaths into single paths, determine the length of such paths to be able to
define a cascade of animations with the correct timing to animate 
stroke-dasharry as intended, following the definition of the M/m command). 
There should be an additional property to control this, in case it is useful 
for some people at all to restart the pattern with each subpath - does this
really have use cases or is this addition only added to describe current 
implementation bugs? ;o)
At least obviously this simplifies the situation for subpaths of zero length
and dashes or gaps of zero length, one always has to care about the 
beginning of the pattern and can forget about the rest ;o)


Olaf

Received on Friday, 18 April 2014 12:33:04 UTC