svg arc path command parsing error on sweep flag

[Tom Shinnick]

Program svgo compressed/simplified SVG file. Output included the <path> command d="..." data string

      m-200-1000 -50 0 a50 50 0 0 1 100 0 50 50 0 0 1-100 0

Only the first arc was seen in Inkscape. All following path commands were ignored.

Using the XML editor the command was changed to

      m-200-1000 -50 0 a50 50 0 0 1 100 0 50 50 0 0 1 -100 0

adding a space between the sweep flag and x value: "1-100" changed to "1 -100". After that both arcs were displayed.

Note that this SVG file is displayed correctly in the browsers FireFox, Chrome, Opera and IE10. From my memory of reading the path parsing rules this sensitivity shouldn't happen. Encountering the '-' minus sign should not cause an error.

Even more worrisome is that when experimenting using the XML editor on the path, when 'set' was clicked the path including and following the problem arc command disappeared! Inkscape is parsing and then replacing with the successfully parsed resulting path. Kind of rude, that.

This is with Inkscape 0.48.4 r9939 running on Windows 8

[su_v (suv-lp)]

It would ease further investigation of the reported issue if you could attach a simplified test case consisting of
1) the original SVG file (unmodified by external optimizers),
2) the modified SVG file as output by svgo,
3) the SVG file from 2 saved after later edits via Inkscape's XML Editor

[Tom Shinnick (tshinnic)]

I've added two attachments, 'before' and 'after' files.

svgo_test1.svg

  <svg xmlns="http://www.w3.org/2000/svg" width="2000" version="1.1" height="1200">
      <path d="M200,200 m -50,0 a 50,50 0 0 1 100,0 a 50,50 0 0 1 -100,0 M200,600 m -50,0 a 50,50 0 0 1 100,0 a 50,50 0 0 1 -100,0 M200,1000 m -50,0 a 50,50 0 0 1 100,0 a 50,50 0 0 1 -100,0" stroke="black" stroke-width="25" fill="none" />
  </svg>

  three circles are seen - these are made from three pairs of arc commands

out.svg (output from svgo program)

  <svg xmlns="http://www.w3.org/2000/svg" width="2000" version="1.1" height="1200">
      <path d="M200 200m-50 0a50 50 0 0 1 100 0 50 50 0 0 1-100 0m50 400m-50 0a50 50 0 0 1 100 0 50 50 0 0 1-100 0m50 400m-50 0a50 50 0 0 1 100 0 50 50 0 0 1-100 0" stroke="black" stroke-width="25" fill="none"/>
  </svg>

  one semicircle is seen - the first 'bad' arc command has killed remainder of display in Inkscape

As for the XML Editor problem...

Open out.svg, select visible shape, "Edit / XML editor",
and the d="..." path value will already be displayed, showing

  M200 200m-50 0a50 50 0 0 1 100 0 50 50 0 0 1-100 0m50 400m-50 0a50 50 0 0 1 100 0 50 50 0 0 1-100 0m50 400m-50 0a50 50 0 0 1 100 0 50 50 0 0 1-100 0

merely click the 'Set' button; everything after the first arc command disappears!

  m 200,200 m -50,0 a 50,50 0 0 1 100,0

This means that if the user is trying to understand what is wrong with a path by experimentation, and the path has a problem or the user accidentally _introduces_ a problem, the data may suddenly disappear partially or completely. This quite violates the principle of least astonishment.

[su_v (suv-lp)]

JFTR: the path in the middle and the one at the bottom in 'out_.svg' render differently than in the original 'svgo_test1.svg' in current web browsers (tested with nightly Chromium, stable Firefox, Opera Developer, Safari), in Batik 1.7 (Squiggle) and with librsvg 2.40.1 (rsvg-view-3) - this seems to me to indicate that the output of svgo is problematic independent of whether Inkscape's handling of the 'svgo-optimized' path data is conformant to the SVG 1.1 spec or not.

[Tom Shinnick (tshinnic)]

Yes, they missed details reading the SVG spec. Bug filed and fix suggested.

"convertPathData: consecutive move commands changed to move & implicit line"
https://github.com/svg/svgo/issues/189

[Tom Shinnick (tshinnic)]

Another parsing bug on arcs...
Please read section "F.6.2 Out-of-range parameters"
    http://www.w3.org/TR/SVG11/implnote.html#ArcOutOfRangeParameters
where it says
    "If rx or ry have negative signs, these are dropped; the absolute value is used instead."

My guilt is generating the path
     "M 12.5,550 a50,50,0,0,0,100,0 a50,50,0,0,0,-100,0 m100,0 l0,-100 a-50,-50,0,1,0,-100,0"
and the final arc command was not displayed in Inkscape (a digit nine missing the bottom loop)

When examined in Inkscape the loop was again missing from display. When examined with the XML editor, selecting the d="..." and then hitting 'Set' button will result in
     m 12.5,550 a 50,50 0 0 0 100,0 50,50 0 0 0 -100,0 m 100,0 0,-100
showing that the final arc command is being discarded by Inkscape as invalid.

If that arc command is put back in but changed to
      a 50,50 0 1 0 -100,0
then all is well, with the final arc command being accepted and the final loop of the digit nine showing up.

Inkscape is declaring fatally invalid arc commands with (yes, completely goofy) radii that are negative. Which sorta goes against the words:
      "... an implementation must make sense of them as follows: ..."

[Roul P. (perhelion1)]

Here another example of the optimizing bug (space or comma left) http://upload.wikimedia.org/wikipedia/commons/archive/b/bf/20150107112349%21Vector-bullet-icon.svg (small bullet, reported on Wikimedia Commons)

[su_v (suv-lp)]

Reproduced with Inkscape 0.48.5, 0.91 r13725 and 0.91+devel r14059.

Test cases (also encountered elsewhere with optimized SVG files) render as expected in Batik 1.7 (Squiggle), rsvg-view-3 (2.40.8), Chromium and Firefox.

[su_v (suv-lp)]

Addendum:
The confirmation refers to the parsing of the arc path data (not to the behavior of the XML Editor to discard the path data which isn't parsed by Inkscape).

[Johannes Höhn (johannes-karl-hoehn)]

This bug can probably be fixed by updating lib2geom to revision 2225:

http://bazaar.launchpad.net/~lib2geom-hackers/lib2geom/trunk/revision/2225

[su_v (suv-lp)]

Fixed with the 2geom update in rev 14226:

Revision 14226: Sync 2Geom to revision 2413.
https://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/14226