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

On Mon, Dec 3, 2012 at 1:09 PM, Rik Cabanier <cabanier@gmail.com> wrote:

>
>
> 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.
>
>
Can we infer some kind of parametric derivative, under the assumption that
the parameter changes by 1 unit for each path segment? It seems that we
would have to, in order to address situations like a cubic closing curve
joining to a straight line initial segment.

You're right that it is hard to make universally intuitive. Although at
least it's generally easy to compute such derivatives.

Cheers,
Stephen.