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 759231 - SVG to PNG conversion strange shapes
SVG to PNG conversion strange shapes
Status: RESOLVED FIXED
Product: librsvg
Classification: Core
Component: general
2.36.x
Other Linux
: Normal normal
: ---
Assigned To: librsvg maintainers
librsvg maintainers
Depends on:
Blocks:
 
 
Reported: 2015-12-09 10:22 UTC by Andrea
Modified: 2017-08-30 15:17 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
PNG error (47.25 KB, image/png)
2015-12-09 10:22 UTC, Andrea
Details

Description Andrea 2015-12-09 10:22:44 UTC
Created attachment 317010 [details]
PNG error

If you try to convert this svg to png https://www.dropbox.com/s/9vpfwm0zmpaknzc/60749.svg?dl=0 a strange black shape appears on the final image (see attachment).

dlemstra quote from image magick forum:
"We just upgraded librsvg to the latest version (2.4.12) in the Windows distribution and we still have this issue. It seems that librsvg does not handle '
' properly. When I remove this from your file I get the correct result."
Comment 1 Massimo 2016-02-11 18:16:40 UTC
This svg contains few <polygon /> elements whose 'points' attributes
are incorrectly parsed because they include \r \n white spaces
that rsvg_css_parse_list does not consider as valid delimiters

https://git.gnome.org/browse/librsvg/tree/rsvg-css.c#n705

and so when they're parsed as numbers

https://git.gnome.org/browse/librsvg/tree/rsvg-css.c#n758

wrong zeroes appear in the point list

https://git.gnome.org/browse/librsvg/tree/rsvg-shapes.c#n152



either rsvg_css_parse_list is wrong and should consider
\r \t as valid delimitors or a similar function that accepts
also \r\t should be used because they're part of the grammar

https://www.w3.org/TR/SVG/shapes.html#PointsBNF
Comment 2 Federico Mena Quintero 2017-08-30 15:17:21 UTC
This is fixed in the master branch, for the 2.41.x series.  I won't be backporting the fix to the 2.40 series, as the parser is rewritten now.