Clarified path data omission rules

[yisibl]

The current spec is only one sentence:

Superfluous white space and separators (such as commas) may be eliminated; for instance, the following contains unnecessary spaces:
M 100 100 L 200 200
It may be expressed more compactly as:
M100 100L200 200
Spec: https://svgwg.org/svg2-draft/paths.html#PathDataGeneralInformation

The SVG compressor needs a clear specification in order to compress white space correctly. There is currently a problem with svgo. I can't be completely sure which implementation is correct.

Original svg

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 750 1125">
    <path d="M448.6,997.7c.2,5.6,16.6,9.4,36.5,8.4s35.8-6.2,35.5-11.8a1.7,1.7,0,0,0-.1-.7c-1.5-5.2-17.3-8.6-36.4-7.7s-34.4,5.8-35.5,11.1Z" fill="green" />
</svg>

Use svgo

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 750 1125">
    <path d="M448.6 997.7c.2 5.6 16.6 9.4 36.5 8.4s35.8-6.2 35.5-11.8a1.7 1.7 0 00-.1-.7c-1.5-5.2-17.3-8.6-36.4-7.7s-34.4 5.8-35.5 11.1z" fill="green" />
</svg>

Use svgcleaner

<svg viewBox="0 0 750 1125" xmlns="http://www.w3.org/2000/svg">
  <path d="m448.6 997.7c.2 5.6 16.6 9.4 36.5 8.4s35.8-6.2 35.5-11.8a1.7 1.7 0 0 0 -.1-.7c-1.5-5.2-17.3-8.6-36.4-7.7s-34.4 5.8-35.5 11.1z" fill="#008000"/>
</svg>

00-.1 it seems that spaces cannot be omitted here.

[fsoder]

Those would be the large-arc and sweep flags, which are either 0 or 1 (single character, not a number) so it should be possible to omit spaces there.

[1] https://svgwg.org/svg2-draft/paths.html#PathDataEllipticalArcCommands

[yisibl]

Thanks for your answers, it seems that many parsers do not support omitting white space. Sketch and Adobe Illustrator also cannot display correctly.

[yisibl]

@fsoder What version of Chrome supports omitting white spaces?

[fsoder]

I couldn't really answer that with precision (i.e which version), but it ought to have been supported for quite a while by now.

[Doktorchen]

The current recommendation 1.1 notes in the implementation requirements:
"Any nonzero value for either of the flags fA or fS is taken to mean the value 1."
https://www.w3.org/TR/SVG11/implnote.html#ArcOutOfRangeParameters

This seems to be in minor stress with the given BNF notation and is missing in the current 2.0 draft (this needs to have the same wording as 1.1 to avoid any imcompatibilities).
But because it is noted as required interpretation of out-of-range parameters, there is no real conflict here in SVG 1.1.

And it has some practical relevance both for animation and for parameter/syntax correction.
However, it is not obvious, if 'Any nonzero value' can mean only one character or more - within the interpolation of an animation this will typically a number, therefore more than one character, but this is not noted by authors in the path d attribute, results only from the animation calculations.
But because the section talks about out-of-range parameters, one has to assume, that any other value than zero has to be corrected to '1'.
In this case '00' is still a valid representation of zero, therefore finally a separation between the flags is necessary to avoid failed presentations due to required corrections or interpretations.

[yisibl]

I'm a little dizzy, so do we need further clarification in the SVG 2.0 draft?

[Doktorchen]

There are often different requirement for presentation programs, parsers and producers of content.
Producers of content are expected to put no nonsense in their documents (here: use nothing different from the characters 0 and 1 for the flags.
Parsers are expectected to take into account, that some documents contain nonsense, therefore there are some requirements to fix this, if possible (here to fix out or range parameters).
In this case this has consequences for content producers: separate these flags to avoid interpretation as nonsense.

[tatarize]

The arc and sweep flags can be combined. However anybody trying to do simple svg parsing without requiring context aware parsing is going to have a bad time with that, but it's clear in the XBNF that that is absolutely valid syntax. 0020 there quite unambiguously 0, 0, 20 much to my distaste for it see #755. If I had god-like backwards compatibility breaking powers I would get rid of svg arc altogether and use R circular arcs. ( #767 ). But, yeah, parsers go ahead and turn those numbers into whatever weird things they want because they are correct within the goofy arc svg has.