Re: zero length dashes

On Fri, Apr 18, 2014 at 5:32 AM, Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>wrote:

> 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.
>

I reread the algorithm [1] and you are right that it does not divide the
path into pieces (I was confused with canvas which does do that)
It also defines what happens with 0 length dashes since they are aligned
with the original path.

I withdraw my earlier proposal


> 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.
>

Can you point to an example what you are trying to achieve?
I had a proposal for border brushes that might be what you are looking for.


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

Are you saying that given a path consisting of sub-paths, the dash phases
of the subpaths should adjust so the dashing is contiguous?


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

1: https://svgwg.org/svg2-draft/painting.html#TermStrokeShape