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

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.

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


> 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 10:14:41 UTC