incorrectly renders SVG

Swiss army knife of image processing

Brought to you by: bfriesen

#94 incorrectly renders SVG

Milestone: v1.0_(example)

Status: closed-fixed

Owner: Gregory J Wolfe

Labels: File Format Support (54)

Priority: 5

Updated: 2018-04-20

Created: 2008-08-04

Creator: Anonymous

Private: No

gm incorrectly renders this SVG (xmonad's logo): http://xmonad.org/images/logo.svg
It draws red line in the bottom, while there should be white background (this is how it's rendered by other software: http://xmonad.org/images/logo.png\)

Roman Cheplyaka <roma@ro-che.info>

Discussion

Bob Friesenhahn - 2008-08-04

labels: --> 595549

assigned_to: nobody --> bfriesen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Bob Friesenhahn - 2008-08-04

Logged In: YES
user_id=128624
Originator: NO

I notice that recent ImageMagick produces the same result as GraphicsMagick. The SVG renderer is pretty weak by today's standards but does usually successfully render such simple graphics.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Bob Friesenhahn - 2011-02-20

labels: 595549 --> File Format Support
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Bob Friesenhahn - 2012-10-20

Problem SVG file

logo.svg

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Bob Friesenhahn - 2012-10-20

PNG file showing expected result

logo.png

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Bob Friesenhahn - 2012-10-20

The bug is that GraphicsMagick is not properly respecting move-to requests ('M') in a path specification. It should treat each move-to request as a request to close the current drawing path and start a new drawing path at the new starting location. This is a problem with the MVG renderer. ImageMagick's built-in SVG reader still has the same bug.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Bob Friesenhahn - 2018-04-18

assigned_to: Bob Friesenhahn --> Gregory J Wolfe

Group: --> v1.0_(example)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gregory J Wolfe - 2018-04-20

status: open --> closed-fixed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gregory J Wolfe - 2018-04-20

This problem has been fixed by the following change set:

changeset: 15585:b5ca60b382d6
tag: tip
user: Greg Wolfe gregory.wolfe@kodakalaris.com
date: Fri Apr 20 09:48:34 2018 -0400
summary: SVG: Process paths containing multiple subpaths correctly.

Details: When a path contained multiple subpaths, only the first one was being handled correctly. For subsequent subpath starts, a test intended to eliminate duplicate points was incorrectly comparing the first point in the new subpath to the last point in the previous subpath. This sometimes caused the first point in the new subpath to be discarded.

Thanks for the example SVG file. It was of great help in finding this bug.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Log in to post a comment.