Re: [svgwg] Serialization format for path strings

> The reason that the path syntaxes (with and without path() function notation) use strings is because implementations did not want to have to parse path data with the CSS parser.

Rather, we *can't* parse path data with the CSS parser; it's written in a way that is wholly incompatible with the CSS tokenizer, and would require *heroic* efforts to reverse the obtained tokens back into reasonable path commands. (If it's even possible at all; without a thorough review, I'm not willing to say that some cases aren't impossible to recover.)  Thus you have to pass it thru the CSS parser as a string, and then do special-case parsing at the impl level.

This doesn't mean it's a "string" in a semantic sense; it doesn't contain arbitrary opaque data. It's very much transparent, and contains meaningful structured data! As such, the computed value of a `path()` is definitely a segment list (probably normalized to some degree).

> Do we need a promotion to Q

While not strictly necessary, doing so means that animating an `L` to a `Q` will output a `Q`, rather than going all the way to a `C`.

> A -> C (?)

You can't convert an arc to a cubic bezier in general. (You can get *very close*, but it's impossible to get a correct perfect equivalence.)  Maybe it's worthwhile to try, tho? If people can animate between arcs and lines (yes), and they can animate between lines and curves (yes), I presume they'd want to be able to animate between arcs and curves.  Doing so, tho, would mean we've have to downgrade the arc into *one or more* curves, which then becomes tricky to animate (subdivide the curve it's animating against into the same number of subcurves? where do place the cuts?). It's a difficult problem with some tradeoffs.

> Also, there is probably a need to briefly address the handling of the new 'B' (bearing) command also, isn't there? I.e. that it affects the following commands, but drops from the normalisation.

That's not necessarily obvious.  Animating a `B 0 h 10` to a `B 90 h 10` looks different depending on whether you elide the `B`s (resulting in a normalized `H 10` and `V 10`, I think?) or don't; the former moves the endpoint in a straight diagonal line, while the latter moves it in a circular arc.

`B` might be similar to a `rotate()` in a transform list - it *could* be interpreted as just rewriting the rest of the transform list, but it's typically used semantically, such that you want to preserve and animate it as a rotation.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/svgwg/issues/321#issuecomment-305347037 using your GitHub account

Received on Wednesday, 31 May 2017 23:30:22 UTC