After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 747428 - SVG path parsing misparses "M 0.6.5"
SVG path parsing misparses "M 0.6.5"
Status: RESOLVED DUPLICATE of bug 620923
Product: librsvg
Classification: Core
Component: general
2.40.x
Other Linux
: Normal normal
: ---
Assigned To: librsvg maintainers
librsvg maintainers
Depends on:
Blocks:
 
 
Reported: 2015-04-06 22:36 UTC by Josh Estelle
Modified: 2015-04-07 17:24 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Example SVG that is incorrectly rendered (822 bytes, image/svg+xml)
2015-04-06 22:36 UTC, Josh Estelle 		Details

Description Josh Estelle 2015-04-06 22:36:10 UTC 
Created attachment 301040 [details]
Example SVG that is incorrectly rendered

From the SVG spec:
http://www.w3.org/TR/SVG/paths.html
quoting 8.3.9:

Similarly, for the string "M 0.6.5", the first coordinate of the "moveto" consumes the characters "0.6" and stops upon encountering the second decimal point because the production of a "coordinate" only allows one decimal point. The result is that the first coordinate will be "0.6" and the second coordinate will be ".5".


I believe this is not being parsed correctly by eog's image viewer.


Here is an example SVG that renders quite terribly:
http://google.github.io/material-design-icons/action/svg/ic_settings_24px.svg

Inlined:
<svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24">
    <path d="M0 0h24v24h-24z" fill="none"/>
    <path d="M19.43 12.98c.04-.32.07-.64.07-.98s-.03-.66-.07-.98l2.11-1.65c.19-.15.24-.42.12-.64l-2-3.46c-.12-.22-.39-.3-.61-.22l-2.49 1c-.52-.4-1.08-.73-1.69-.98l-.38-2.65c-.03-.24-.24-.42-.49-.42h-4c-.25 0-.46.18-.49.42l-.38 2.65c-.61.25-1.17.59-1.69.98l-2.49-1c-.23-.09-.49 0-.61.22l-2 3.46c-.13.22-.07.49.12.64l2.11 1.65c-.04.32-.07.65-.07.98s.03.66.07.98l-2.11 1.65c-.19.15-.24.42-.12.64l2 3.46c.12.22.39.3.61.22l2.49-1c.52.4 1.08.73 1.69.98l.38 2.65c.03.24.24.42.49.42h4c.25 0 .46-.18.49-.42l.38-2.65c.61-.25 1.17-.59 1.69-.98l2.49 1c.23.09.49 0 .61-.22l2-3.46c.12-.22.07-.49-.12-.64l-2.11-1.65zm-7.43 2.52c-1.93 0-3.5-1.57-3.5-3.5s1.57-3.5 3.5-3.5 3.5 1.57 3.5 3.5-1.57 3.5-3.5 3.5z"/>
</svg>
Comment 1 Felix Riemann 2015-04-07 17:20:32 UTC 
Hi!

eog's SVG support is actually provided by librsvg.

I couldn't spot a difference between eog and Inkscape's rendering using librsvg-2.40.8. But as librsvg (and it's path parser) received quite some updates lately I tried again with 2.40.5 and the image got corrupted there.

As of 2.40.6 (specifically commit 5ba4343bccc7e1765f38f87490b3d6a3a500fde1) the picture renders correctly to me, making this a likely duplicate of bug 620923.
---
Thanks for taking the time to report this.
This particular bug has already been reported into our bug tracking system, but we are happy to tell you that the problem has already been fixed in the code repository.

*** This bug has been marked as a duplicate of bug 620923 ***
Comment 2 Josh Estelle 2015-04-07 17:24:44 UTC 
Awesome.  Thanks for the detailed follow up Felix.

I believe you're right, and I'm happy to hear it has been fixed.