I am running into this same issue and I think that Ghostscript 9.22 is the problem. I can reproduce the issue by running Ghostscript directly:
gs -dSTRICT -dDOINTERPOLATE -dNOPAUSE -dEPSCrop -dBATCH -sOutputFile=test.png -sDEVICE=pngalpha /path/to/broken.pdf
I've also tested with Ghostscript 9.21, which works as expected.
When imagemagick's convert
command is run with +antialias
, it passes different switches to ghostscript.
You can use the -verbose
switch to tell imagemagick to print out the entire command it is using to invoke gs
:
$ convert -verbose test.pdf test.png
Which yields:
'gs' -sstdout=%stderr -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=2 '-sDEVICE=pamcmyk32' -dTextAlphaBits=4 -dGraphicsAlphaBits=4 '-r72x72' -g1728x1728 -dEPSCrop ...
With the antialias flag set:
$ convert -verbose +antialias test.pdf test-with-antialias-flag.png
gives us:
'gs' -sstdout=%stderr -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=2 '-sDEVICE=pamcmyk32' -dTextAlphaBits=1 -dGraphicsAlphaBits=1 '-r72x72' -g1728x1728 -dEPSCrop
There are a couple of different switches set there. Based on some experimentation running gs
directly, I figured out that -dGraphicsAlphaBits
seems to be the culprit. If it is set to a value greater than 1, the lines appear in the output.
So there are a few potential workarounds:
- Edit imagemagick's delegates.xml to force
-dGraphicsAlphaBits
to 1.
- Install ghostscript 9.21, which seems unaffected.
- Convert at double dimensions and then size down, as suggested above.