W3C home > Mailing lists > Public > www-svg@w3.org > December 2012

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

From: Rik Cabanier <cabanier@gmail.com>
Date: Mon, 3 Dec 2012 10:09:51 -0800
Message-ID: <CAGN7qDDK7OwzmNWiRsx+QFQwB5EBvyThXn3XDmZ-Tin5KTaRPw@mail.gmail.com>
To: "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de>
Cc: www-svg@w3.org
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
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.
Received on Monday, 3 December 2012 18:10:19 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:30 UTC