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

On Mon, Dec 3, 2012 at 4:13 AM, Dirk Schulze <dschulze@adobe.com> wrote:

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


True.
In my original email I forgot to mention the 'arc' related commands. Since
the spec doesn't describe how those are broken into beziers, this new
command can't work the same across UA's.
If Catmull-Rom curves become part of the syntax, how would they work?


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