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

On Dec 3, 2012, at 2:14 AM, Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de> wrote:

> Rik Cabanier:
>> Hi Dr Olaf,
>> 
>> I have a couple of concerns with your proposal.
>> 
>> 1. If we go this route, UA's will have to remember the first and last
>> control point in case this operator is used. This will introduce some
>> overhead.
> 
> Well, for Z one has already do remember the first point of a subpath.
> And if you have d="M0,0 1,1 1,0ZL-1,-1 -1,0ZL-1,1 0,1Z"
> the program already has to identify the right starting point for the
> L commands from the history of the path.
> 
> And for S (and T) one has to remember the previous point and the
> direction of the path for this point. To get the direction for markers and
> linecaps and linejoins right, one has to explore the path data 
> (especially marker directions are still often wrong in several viewers 
> today for specific conditions, where it is not  simple to determine the 
> direction of the path - I have examples as well for linejoins, in all viewers
> wrong, which I tested). 
> I think, there is an advanced set of marker positions already in the 
> SVG 2 draft, that requires even more exploration of the path data 
> to get this right.
> Compared to markers, linecaps and linejoins the situation with this
> new path command is quite simple, if only corresponding rules as
> for S are used.
> Of course to get better results for authors one could improve the
> rules to get the direction in problematic cases for S and T as well,
> but I think due to problems with backwards compatibilities it is too
> late for a change here, therefore no need to introduce more advanced
> rules for this new command as well.

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.

> 
>> 2. We are trying to harmonize our path operators with Canvas. If we add
>> this to SVG, we need to have it in Canvas as well.
> 
> This seems to be more an advantage for those, which use already (or still?) 
> canvas.
> Because there are ideas to add other path commands as well to SVG2,
> altogether this seems to be a progress for canvas authors, they can
> benefit from the progress in SVG2, if this is adjusted in canvas.
> Is there already a recommendation or specification of canvas? 
> Maybe only a draft, therefore not much to worry about...
> The HTML5 draft anyway notes:
> 'Authors should not use the canvas element in a document when 
> a more suitable element is available.'
> I think, due to accessibility concerns practically there is always a
> better element/markup available.
> 

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.

Greetings,
Dirk

> 
>> 3.Beziers have the peculiar property that they can draw even if the start
>> and end point are the same. So, if the last point coincides with the start
>> point and you use this new operator, you will see a small oval. This is
>> most likely not desired.
> 
> The same applies for many other commands, if you need only straight
> lines, the commands C, S, Q, T can be a source of complication, if you
> use them (but if you want to morph from a straight line to something else
> with an animation, they can be pretty useful even for straight lines).
> If one does not need this new command, one can still use Z to close
> the path, this is expecially important for backwards compatibility, because
> today one has to calculate the last S control point manually, followed by
> a Z. 
> 
> Or if we use ß at the moment as a name for the command:
> d="M0,0ß" will be the same as d="M0,0Z"
> Even for d="M0,0 1,ß", if the corresponding rules as for S are used,
> this is the same as d="M0,0 1,1C1,1 0,0  0,0Z".
> 
> Problematic cases are already frustrated for the commands S and T
> with specific rules, therefore nothing interesting for authors happens,
> if those commands are used in more problematic combinations
> as QS, LS, CT, LT, MS, MT, ZS, ZT etc. If similar rules are used 
> for this 'ß', there is no situation left, where programs have to do 
> complex calculations.
> 
> Olaf
>

Received on Monday, 3 December 2012 12:20:25 UTC