Re: zero length dashes

Rik Cabanier:

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

For example: 
a) I want to have round linecaps for a path but no round caps for the dashes -
they should have exactly the length given by the property stroke-dasharray and
no caps at all.
b) I want to have other caps for the dashes than for the subpaths and the 
stroke-dasharray pattern should continue within the linecaps. 
c) I want an animation that draws a curve with linecap round, but I do not
want the 'moving' end of the visible path fragment to be round as the 
linecaps.
d) I want to provide visible dashes smaller than the width of the stroke, even
if the stroke-linecap is not 'butt'.

Currently to get parts of this, maybe the simplest approach is to work with an 
additional manually extended path simulating  stroke-linecap square, applying
to this the intended stroke-dasharray and realising the intended 
stroke-linecap by applying to this the original path with the intended 
stroke-linecap as a mask. For arbitrary dash-caps one may have to construct
the complete mask manually and using this instead of the stroke-dasharray
on the manually extended path - a lot of work to get this without one or two
additional properties, that define the behaviour of dash-caps independently
from that of linecaps. 


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

Yes, sure, with animation my typical use case is to animate the stroking
of a path - for this use case and maybe several others it is pretty 
contraproductive, if the pattern restarts with each subpath.
You want only one end in motion for the complete path.

For example if you want to simulate how a comic painter draws a 
portrait of a person, it is simple to get this, if the dash continues 
as the progress of the complete path does.
If it restarts with each subpath, you are really in trouble. 
Due to a related bug in browsers I already had to calculate for hours
only for one portrait of this type to work around the problem.

Currently the recommendation (SVG 1.1) notes for M/m:
'The "moveto" commands (M or m) establish a new current point. The effect is 
as if the "pen" were lifted and moved to a new location.'
And for stroke-dasharry:
'‘stroke-dasharray’ controls the pattern of dashes and gaps used to stroke 
paths. <dasharray> contains a list of comma and/or white space separated 
<length>s and <percentage>s that specify the lengths of alternating dashes 
and gaps.'

Therefore clearly the pattern has to continue in the next subpath at the
position of the pattern, it has ended for the previous subpath - 
only the 'pen' is lifted and moved to the new location and stroke and
pattern are continued.

This means clearly, that current viewers restarting the pattern with each
subpath have a bug and this means as well, that the draft for SVG 2
is backwards incompatible and inconsistent.

But if there are use cases for restarting the pattern with each subpath,
there should be a new property to allow authors to control this behaviour.
At least, without control it is much easier to simulate the restart behaviour.
One only has to split the path, group them together with a g element and
applying the stroke-dasharray to the g element, this does not require
lot of calculations, 'only' splitting the path - what is still some work.
I think, because the SVG draft has proposals as well to join paths
to a superpath, one still has to explore, if this could help in case of 
intersecting paths relevant for fill-rule and opacity issues 
(but I did not find it in the current draft, maybe already given up?)

Olaf

Received on Saturday, 19 April 2014 12:18:43 UTC