Regression for -density has some sort of rounded off internal low resolution for SVG, making many outputs impossible

[johnkw]

ImageMagick version

7.1.1-26

Operating system

Linux

Operating system, version and so on

Linux Fedora

Description

There's nothing particularly special about the SVG that I can find. It does this for any SVG I tested, but see this example:

$ cat bug.svg
<svg width="306" height="306" xmlns="http://www.w3.org/2000/svg"><path d="M0 0h306v306"/></svg>
$ convert -density 313.50 bug.svg bug.jpg && identify bug.jpg
bug.jpg JPEG 998x998 998x998+0+0 8-bit Grayscale Gray 256c 8900B 0.000u 0:00.000
$ convert -density 313.51 bug.svg bug.jpg && identify bug.jpg
bug.jpg JPEG 1001x1001 1001x1001+0+0 8-bit Grayscale Gray 256c 8943B 0.000u 0:00.000
$

So it jumps forward 3 pixels at a time, making it impossible to render a 1000x1000 image.

I found an old version 7.0.10-13 and it does not have this bug. So it's a regression somewhere between those two. It's probably fairly recent. I think some Fedora update probably hit me with this recently.

Steps to Reproduce

.

Images

No response

[Fred Weinhaus]

Are you using the same SVG renderer on both systems in Imagemagick. Imagemagick can use Inkscape if on your system, RSVG delegate if installed with Imagemagick or the Imagemagick XML/MSVG rendered. The latter two would show for SVG if you do

magick (or convert as appropriate) -list format

or

add -debug to your commands and compare the debug listings.

[johnkw]

Thanks much!

So this is pretty hilarious. The old one, which works, was using --export-file= for the inkscape delegate line. That command line is broken because inkscape requires it to be --export-filename.

So the one with the old broken command line WORKS because inkscape generates an error Unknown option --export-file=, and then IM falls back to some internal library which apparently does work.

The new one with the correct command line is now broken because it outputs --export-dpi='314' with a truncated integer instead of the full floating point value. The old one seems to also have that same bug, but it never mattered because the broken command line --export-file= allowed it to bypass that bug entirely. So presumably the regression occurred whenever the --export-filename fix was made.

Oh and for anyone wondering, a temporary workaround for this regression is to edit /etc/ImageMagick-7/delegates.xml and change the <delegate decode="svg:decode" bit so IM just can't find it at all, like <delegate decode="brokensvg:decode".

[Cristy]

Thank you for reporting the issue. We have successfully reproduced it and are actively working on a patch to resolve it. You can expect this patch to be merged into the main GIT branch, later today. As part of our commitment to quality, this fix will also be included in the upcoming beta releases of ImageMagick by tomorrow. Your patience and feedback are greatly appreciated.

[johnkw]

Awesome, thanks. (Strange that the I see the original --export-file --export-filename thing that allowed this to work previously was actually fixed 4 years ago, unless I'm looking at the wrong file. ImageMagick/ImageMagick6@ba8df11 I wonder if somehow dnf wasn't updating that file previously or something. Or maybe something different about inkscape made it start working in order to break this. In which case maybe it wasn't a regression for some Fedora installs, but was a regression for others.)