If the input file contains an image, the image gets stretched in one direction
and shrinked in the other.
/usr/bin/gs -q -dNOPAUSE -dBATCH -dSAFER -sDEVICE=ps2write -sOUTPUTFILE=%stdout
-dLanguageLevel=2 -r600x1200 test.pdf > test.ps
with the attached PDF file demonstrates the problem.
Created attachment 5062 [details]
PDF file which ps2write does not render correctly in 600x1200dpi
This is not caused by the presence of an image as such. The original PDF file
does not simply place an image, it creates a pattern colour space which uses an
image, then fills an area using the pattern colour space.
The problem is not specific to ps2write, the same effect can be seen with
pdfwrite. I believe this is because the matrix is incorrectly calculated for the
pattern and the image used by the pattern. Converting to PDF makes the files
easier to examine, and in this case the only differences in the files are the
two matrices and the area to be filled.
While this is a bug, it is much less serious than the presence of images causing
a problem, also it can easily be worked around by not setting a non-square
In fact the main purpose of the resolution parameter is when flattening
transparency into an image (there are some other objects which can also be
flattened), this is intended to produce an image at a reasonable resolution for
the intended output device. In general this resolution will be less than the
resolution of the outputdevice, though making it the same will generally only
mean a larger output file.
So there really isn't any reason to use a non-square resolution.
As a rule we need an adobe distiller example that differs from pdfwrite to have
I do not have Adobe Distiller handy. I have based the bug report on the image
appearing stretched/shrinked when displaying the resulting PostScript file with
Using the smaller of the two resolutions as a square resolution solves the problem.
If you do not think this should be fixed for having better usability (every
resolution setting simply works), at least by internally using the smaller of
the two resolutions, mention at least in the documentation that
pdfwrite/pswrite/ps2write should always be used with a square resolution.
Henry, Till, if you run this through Acrobat you will get the 'correct' answer,
because the pattern shouldn't depend on the output resolution. Remember I can
get the same problem converting to PDF which is resolution-independent.
It looks to me like the matrix and area for the pattern fill are incorrectly
calculated (possibly x/y scaling confusion looking at the output) when the
output resolution is non-square. I agree this is a bug, and am happy to look
into it at some point.
However, the fact that it only affects images drawn using a Pattern colour
space, when the resolution is non-square moves it to a less serious failure,
because its an unusual (and frankly daft) way to draw an image and can easily be
solved by not using a non-square resolution.
So I'd like to leave it as an open bug.
Note that cairo generally draws images as pattern colour spaces, so such files
are increasing common.
The problem was caused by the calculations which remove the resolution scaling from the CTM when the pattern is defined, in order to create the pattern matrix. This was done by simple arithmetic, which doesn't work well with matrix algebra, and fails badly when (as in this case) the pattern matrix involves a rotation.
Fixed in revision 11699, patch here: