Daniel Kahn Gillmor
2012-01-13 22:54:08 UTC
Package: imagemagick
Version: 8:6.6.9.7-5+b2
When i convert a jpeg to a postscript file using /usr/bin/convert from
imagemagick, the generated postscript contains a function named
DisplayImage which uses gsave without using grestore.
This appears to work initially, but causes some serious problems when
the .ps file gets used in other places (e.g. /usr/bin/poster, which
carves up a postscript file and makes it into a multi-page postscript
file that can be taped back together poster-size, from the "poster"
package in debian).
You can see the results of this sort of failure by starting with an
50x38 jpeg:
convert x.jpg x.ps
poster -m Letter -p 22x15i x.ps > x-poster.ps
Look at the position of the cut-marks and labels on the resultant pages
with and without the grestore invocation at the tail of DisplayImage.
If you want to examine it, I'm attaching a tarball that contains:
x.jpg (original jpeg)
x.ps (converted with stock imagemagick)
x.fixed.ps (x.ps, with grestore added to DisplayImage)
x-poster.ps (posterized version of x.ps)
x.fixed-poster.ps (posterized version of x.fixed.ps)
I believe the fix should be something like the patch to ps2.c below (i'm
not sure how convert decides to use ps.c, ps2.c, or ps3.c -- ps.c and
ps3.c may also need to be fixed).
I note that graphicsmagick's convert routines (at least in gm 1.3.12)
contain the grestore invocation, fwiw.
I'm not subscribed to magick-bugs -- please CC me in any replies.
Regards,
--dkg
--- a/imagemagick-6.6.9.7/coders/ps2.c 2012-01-13 17:39
+++ b/imagemagick-6.6.9.7/coders/ps2.c 2012-01-13 17:39@@ -369,6 +369,7 @@
" currentfile buffer readline pop",
" token pop /compression exch def pop",
" class 0 gt { PseudoClassImage } { DirectClassImage } ifelse",
+ " grestore",
(char *) NULL
};
Version: 8:6.6.9.7-5+b2
When i convert a jpeg to a postscript file using /usr/bin/convert from
imagemagick, the generated postscript contains a function named
DisplayImage which uses gsave without using grestore.
This appears to work initially, but causes some serious problems when
the .ps file gets used in other places (e.g. /usr/bin/poster, which
carves up a postscript file and makes it into a multi-page postscript
file that can be taped back together poster-size, from the "poster"
package in debian).
You can see the results of this sort of failure by starting with an
50x38 jpeg:
convert x.jpg x.ps
poster -m Letter -p 22x15i x.ps > x-poster.ps
Look at the position of the cut-marks and labels on the resultant pages
with and without the grestore invocation at the tail of DisplayImage.
If you want to examine it, I'm attaching a tarball that contains:
x.jpg (original jpeg)
x.ps (converted with stock imagemagick)
x.fixed.ps (x.ps, with grestore added to DisplayImage)
x-poster.ps (posterized version of x.ps)
x.fixed-poster.ps (posterized version of x.fixed.ps)
I believe the fix should be something like the patch to ps2.c below (i'm
not sure how convert decides to use ps.c, ps2.c, or ps3.c -- ps.c and
ps3.c may also need to be fixed).
I note that graphicsmagick's convert routines (at least in gm 1.3.12)
contain the grestore invocation, fwiw.
I'm not subscribed to magick-bugs -- please CC me in any replies.
Regards,
--dkg
--- a/imagemagick-6.6.9.7/coders/ps2.c 2012-01-13 17:39
+++ b/imagemagick-6.6.9.7/coders/ps2.c 2012-01-13 17:39@@ -369,6 +369,7 @@
" currentfile buffer readline pop",
" token pop /compression exch def pop",
" class 0 gt { PseudoClassImage } { DirectClassImage } ifelse",
+ " grestore",
(char *) NULL
};