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] test.pdf 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 resolution. 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 a bug.
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 Ghostscript. 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: http://ghostscript.com/pipermail/gs-cvs/2010-September/011716.html