Re: SVG2 - suggestion for a new path command to close a subpath smoothly

Dirk Schulze:
...
>
> SVG paths already require a lot of storage of values, like for the control
> points of the previous segment for a shorthand like T. But it is indeed not
> required to cache more than that. The Z is done by the graphic library
> under the hood. Implementations mostly don't need to store the first point
> of a path and just have a look before of one segment at the moment.
>

To get markers at corners right, one has to determine both the 
direction before and after the corner to get it right - to get it right
can be more complex than just looking for control points in both
directions.
Even worse, if a cubic segment creates a corner within the segment.
To get the linejoin right here, one has to analyse the path to
find out, that there is a corner at all.
Compared to this already existing issues, it looks like a simple
task just to take points from the beginning of the subpath again -
this requires no deeper analysis of the path data.

And as Jasper van de Gronde already mentioned, with a
general option to close a path one can avoid problems due to
numerical accuracy limitations. And authors can avoid unintended 
effects of zero length Z on markers in most cases.

Therefore I think, there are a much more benefits than disadvantages.
And I think, the advantages are of much more practical relevance 
as for the new suggested path commands than arcTo, which are
quite nice for authors as well of course.
Because those will cause already major problems to view new SVG2
documents with old viewers, it is of some relevance now to add at
least all useful new commands and trying to avoid to add more in
maybe five or ten years in SVG3, because it turns out, that they are
really missing.
Such a major change of SVG path data has to be considered 
carefully. And it is only worth to change something at all in SVG2
path data, if the change covers at least such applications, which
are already known to be useful.

>
> The accepted new path segments are harmonizing Canvas and SVG more. We will
> support the arc and arcTo of Canvas in SVG. My concern is the increasing
> complexity of the path syntax. The authors of SVG 1 tried to limit
> everything to one letter. This is kind of a burden now, even if it still
> has benefits.
>

As already mentioned, we have the problem, that old viewers will not manage 
to interprete new syntax, but path data are a fundamental part of SVG.
Therefore only to introduce these two useful, but not essential commands
is not enough. But there will be new commands due to ACTION-3085
(requirement for smooth interpolation between points) - therefore to be 
able to close the path smoothly fits as well to this effort to get things 
easier to work for authors. It completes the already accepted task to 
improve path data.
These arc commands are only a small part of it.
And only if we get everything at once, it is worth to change the syntax
now in SVG2. 

If it is only intended to keep things simple for SVG-viewers, the path data
syntax should not be changed at all, no new commands from canvas,
no smooth interpolation between points etc. And better to skip features
like markers, stroke-dasharray etc, because viewers do not manage them
today - maybe an indication, that such programs are not clever enough
to present advanced vector graphics ;o)
And the problems with stroke-dasharray (there are previous discussions)
show already, that the results from graphic libraries are not reliable 
anyway - maybe they are not clever enough as well to interprete
advanced vector graphics - or the SVG viewers should not delegate
advanced tasks to libraries, which do not care about the concepts of SVG.

Olaf

Received on Monday, 3 December 2012 14:26:55 UTC