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: Stephen Chenney <schenney@chromium.org>
Date: Mon, 3 Dec 2012 09:49:22 -0500
Message-ID: <CAObCcUpsOB6M9k34cJ5XhEdvD+tR+8c+DFO2hxUv_GTqdijMjQ@mail.gmail.com>
To: Jasper van de Gronde <th.v.d.gronde@hccnet.nl>
Cc: www-svg@w3.org
I believe that Jasper's suggestion can be rephrased as "provide a method to
reference the first point in the path symbolically". That reference is the
"flag" he talks about. We could still use Z to refer to that point, and
view a lone Z as L Z.

This does allow smooth cubic closing if you overload the "S/s" verbs to
have the obvious meaning when closing. The degenerate cases require thought
but not intractable.

Rik and Dirk are right in saying that the UA back end rendering libraries
would need to be modified to handle this new path feature efficiently.

I think this is a very useful feature to have because it is useful, it
generalizes the existing close verb, and it is orthogonal to other
features. (An orthogonal feature is one that can be applied in any
situation and is not already covered by an existing feature).

But I think the implementation hassles are significant and, regardless of
what Olaf might say, an SVG feature that nobody implements may as well not
exist. My prediction is that UAs could implement this but (a) it won't
happen soon and (b) it probably won't happen at all unless Canvas needs it
too.

Stephen.

On Mon, Dec 3, 2012 at 7:45 AM, Jasper van de Gronde <
th.v.d.gronde@hccnet.nl> wrote:

> On 03-12-12 12:37, Dr. Olaf Hoffmann wrote:
> > Jasper van de Gronde:
> >> I would suggest, though, to rethink the naming scheme. Essentially you'd
> >> want ANY path command to be able to close a subpath (why allow a cubic
> >> Bézier, but not an arc for example). So if they all get letters, that's
> >> a lot of letters. Instead, I would suggest letting an author "flag" when
> >> a path command should close a subpath.
> >
> > With a cubic curve you can close the path smoothly, because you have
> > enough parameters, two control points. For example with a quadratic path
> > you have only one control point, therefore typically the path cannot be
> > closed smoothly. With elliptical arcs - does it work in general? If you
> have
> > multiple arc commands following each other with different half axis and
> > alignments, are you sure you can close such arc paths smoothly with only
> one
> > arc command? Currently we do not even have something corresponding to
> > S and T for the A command to connect different elliptical arc segments
> > smoothly.
>
> I didn't necessarily mean closing /smoothly/ here. I split your
> suggestion in two: being able to close a subpath with something other
> than a straight line (smoothly or not) and being able to close it
> smoothly. The smooth part is indeed mostly useful for cubic Béziers.
>
> Just a reminder for why it is useful to be able to close a subpath with
> something other than a line segment (regardless of whether or not you'd
> be able to do it smoothly):
>  - It is more efficient (no duplication of coordinates).
>  - No duplication of coordinates means less chance to make mistakes when
> changing them (through animation or otherwise).
>  - Inkscape (and possibly others) wouldn't have to either contend with
> bug reports about spurious nodes or implement a series of "hacks" to
> implement its own logic on top of the SVG close path command.
>  - A zero-length line segment can have a visible impact if markers are
> used.
>  - It just plain makes sense.
>
> I never considered allowing a "smooth close" command as well, but it is
> indeed a brilliant addition. But I think it would only make sense if one
> would be able to close subpaths with something other than a line at all.
> It would be weird if one could only use a Bézier to close a subpath
> smoothly...
>
> As for the question of allowing a smooth command for arcs or mixed curve
> types, that's a different (although interesting) question. I purposely
> did not assume any such thing in writing my email.
>
>
>
Received on Monday, 3 December 2012 14:49:54 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:53 GMT