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

On Mon, 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.
>

True. However, that's just 1 value that doesn't change during path
execution.
With your proposal we'll always need 3 and one of them will change for
every operation.


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

Markers will not be used as many times as simple path. I agree that the
overhead there is not significant.


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

That is correct. However, authors might just use this operator to get nice
end joins and will be very confused if they get 'bubbles' when start and
end point overlap.


> 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.
>
>
Thinking about this some more, the issue is not just with coinciding
begin/end points.

Your proposal talks about the 'direction' of the control point, but not its
'strenght' (= how far is it from the anchor point). Maybe if you can spec
that our somehow, we can mitigate this particular issue.