#306 gm fails to convert svg to jpeg if svg has images with negative coordinates

[Sayan Bhattacharyya]

Hi,

"gm convert input_file.svg output_file.jpg" crashes with segmentation fault if the SVG has images with negative starting x coordinates. Here's an example of such an svg:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="344" height="243" viewBox="0 0 737 521">
<defs id="layout_defs">
    <clipPath id="clip_svg_6">
        <rect height="456.44534" width="327.98859" y="31.299" x="29.75235" fill-opacity="1" class="layoutClipper"/>
    </clipPath>
    <clipPath id="clip_svg_9">
        <rect height="312.9911" width="327.98859" y="31.95" x="379.25906" fill-opacity="1" class="layoutClipper"/>
    </clipPath>
</defs>
<g class="main">
    <title>Main</title>

    <image xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="a.jpg" x="-148.647" y="31.2992" width="684.7873" height="456.4453" class="layoutBox" clip-path="url(#clip_svg_6)" id="svg_6">29.75235 31.299227 327.988587 456.445344</image>
    <image xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="b.jpg" x="379.2591" y="-57.6377" width="327.9886" height="492.169" class="layoutBox" clip-path="url(#clip_svg_9)" id="svg_9">379.259064 31.9513 327.988587 312.991089</image>
</g>
</svg>

When the images in this SVG are adjusted to make the x coordinates 0 or positive, it works.

Note: This works fine with ImageMagick.

[Sayan Bhattacharyya]

On Windows, I get:

gm convert: Non-conforming drawing primitive definition (image).

[Bob Friesenhahn]

Please attach the problem SVG file to this issue wrapped up in a zip file, or compressed with gzip. Sourceforge's web site may alter what you pasted in, and it may simply render an attached SVG file for viewing, losing the original.

[Glenn Randers-Pehrson]

I was able to download the svg file by copy-paste from the message. Verified that GM-1.3.18 and GM-1.4 crash and IM displays the image. I wouldn't say IM "works fine" though, because it appears to ignore the offsets. Note you need to create a.jpg and b.jpg (I simply used xc:pink and xc:blue with -size 32x32).

[Alexandre Goloskok]

I've attached a test file with a sample SVG and image that fails with GM and works on IM.

I wouldn't say IM "works fine" though, because it appears to ignore the offsets.

This does not seem to be the case for me. As tested with the attached image on ImageMagick:

<image xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="a.jpg" x="-148" ... >

<image xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="a.jpg" x="-48" ... >

It also renders the same in Chrome browser.

And with GraphicsMagick:

gm convert test.svg gm.jpg
gm convert: Non-conforming drawing primitive definition (image).

[Glenn Randers-Pehrson]

Oops, with my test "a.jpg" and "b.jpg" obviously I couldn't see the offset effect. So yes, IM is working fine.

[Bob Friesenhahn]

On Sat, 11 Jul 2015, Glenn Randers-Pehrson wrote:

Oops, with my test "a.jpg" and "b.jpg" obviously I couldn't see the offset effect. So yes, IM is working fine.

Take care with deciding that "IM is working fine" because in most
installations, ImageMagick is not using its own SVG renderer.

It looks like refering to the input like "MSVG:file.svg" is supposed
to cause ImageMagick to use its own SVG renderer.

Bob

Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/

[Sayan Bhattacharyya]

The IM command "convert MSVG:input_file.svg output_file.jpg" seems to be working fine for me.

[Bob Friesenhahn]

This SVG reveals that there are at least two bugs present. Code in render.c converts a negative number (-90) into a huge unsigned positive number (18446744073709551526) and code in pixel_cache.c fails to defend itself from it, possibly due to integer overflow in the validation code.

[Bob Friesenhahn]

The crash is fixed by Mercurial changeset changeset 14637:d55d7e113315. Please report any other issues you may encounter.