Re: incorrect/inconsistant statements for relative path commands with multiple segments

While I agree the language could be clearer, each curve segment is
considered a separate "command", regardless of whether or not it starts
with a letter.

See the comment about omitted letters (
https://www.w3.org/TR/SVG2/paths.html#PathDataGeneralInformation):

   - The command letter can be eliminated on subsequent commands if the
   same command is used multiple times in a row (e.g., you can drop the second
   "L" in "M 100 200 L 200 100 L -100 -200" and use "M 100 200 L 200 100 -100
   -200" instead).

(although that comment is also inconsistent, because the "M" command has
special rules for omitted letters)

The entire section could use a re-write. There are open issues on GitHub
about the syntax grammar not matching the prose (
https://github.com/w3c/svgwg/issues/325).

On 22 June 2017 at 10:08, Philippe Verdy <verdy_p@wanadoo.fr> wrote:

> In section:
>   - "8.3.6 The cubic Bézier curve commands"
>
> The description of the relative curve ("c") containing multiple segments
> is incorrect, it says:
>
>   "At the end of the command, the new current point becomes the final
> (x,y) coordinate pair used in the polybézier."
>
> However all tests I have seen do not set the new current point at and of
> the "command"', but at end of each bezier curve (as if there was a separate
> "c") command in the middle of the sequence, i.e.
>    "c" (x1 y1 x2 y2 x y)+
> is effectively interpreted as equivalent to:
>    ("c" x1 y1 x2 y2 x y)+
>
> This is what Chrome, IE, Firefox are currently doing in their
> implementation. I have not tested what Adobe tools or other SVG drawing
> programs are doing (including in SVG font renderers that start being
> implemented too in browsers).
>
> The same applies to the relative "s" (smooth) version, and the quadratic
> "q" and "t" (smooth) relative commands, as well as for the relative
> elliptic arcs "a" which may also specify multiple curved segments in the
> same command. See sections:
>
>   - "8.3.7 The quadratic Bézier curve commands"
>   - "8.3.8 The elliptical arc curve commands"
>
>
> This difference of interpretation has no importance for the absolute
> commands, but they have consequences on the relative versions because
> additional control points and endpoints are not specified relatively to the
> same "current point" (so the relative coordinates are not the same for the
> following bezier segments in the same command !).
>
> This is inconsistant (because this is different from what is done for
> relative polylines "l", where the new current point is set **only** at end
> of the polyline and not after each segment), but this should be more
> clearly stated.
>
> An erratum is clearly needed, because the current specifications create
> confusion !
>
> I think that some renderers could also interpret the specification as is,
> producing different results than what is rendered in Chrome/IE/Firefox for
> HTML5 or native SVG documents or in SVG fonts. And some renderers
> (converting an SVG to bitmap) may have different behavior (this should be
> signaled and tested so that everyone will agree with that.
>
> Relative curves with multiple segments are not exceptional, they are used
> in existing corporate logos already published and generated. You should not
> change from what is implemented in major browsers even if it deviates from
> what is currently a recommanded (but not very clear) specification.
>