The customer reports and I've verified that the following command line results in a vertically squished output image: bin/gs -dDOINTERPOLATE -r300 -o test.tif -sDEVICE=tiffg4 \ ./HVAC10_Training_Center.pdf
This is possibly a regression. Though based on the log message it's likely the DOINTERPOLATE flag was being ignored before this commit: commit 045e544c507b151daebc19aaf21a8b13b6c4a844 Author: Robin Watts <robin.watts@artifex.com> Date: Mon Oct 22 17:31:27 2012 +0100 Support rotated images with interpolation. See bug 690246. Testing this on the cluster with a patch that enables interpolation for all landscape jobs reveals no problems.
My recommendation is that Robin work on this when he returns from vacation. If the customer cannot wait until then, he returns August 13, we'll have other folks look at it.
I have identified the problem, and I have a fix locally. It's not pretty though, so I will give some thought to a better version.
Fixed in: commit 61fab280098bcbde6af7bfb317c879754f8a420e Author: Robin Watts <robin.watts@artifex.com> Date: Thu Aug 15 12:23:23 2013 +0100 Bug 694451: Solve problems with interpolated landscape images. The portrait image code accumulates pixels into scanlines, and then plots the whole scanline at once. The landscape image code follows this lead by accumulating pixels into 'scancolumns' and then plots the whole column at once. Unfortunately this accumulation for columns goes wrong in the case where we are working at < 8 bpp (as the transposition of rows to columns fails). This causes images with runs of identical pixels in to be 'squished' vertically. We work around this here in the < 8 bpp case by repeating the writes of each pixel so whole bytes are filled. This is suboptimal, but doing anything else is tricky with the macros the way they are. I have a couple of follow on commits to this to improve the behaviour slightly, but the overall suboptimality of repeatedly accumulating the same pixel is not resolved.
Customer confirms this fixed.