[cups.development] Filters and rotation

[Helge Blischke]

Tim Waugh wrote:

> Hi,
> 
> I'm trying to track down a problem with a queue that uses a
> foomatic-based driver, and I'm trying to work out exactly when a job
> documented should be rotated, and what assumptions each filter may make.
> 
> The background is that I am using CUPS-1.3.7, and I have a landscape PDF
> document.  The filter chain goes:
> 
>   pdftops ( -> pstops ) -> foomatic-rip ( -> gs ) -> backend
> 
> The problem is that while my input document looks like this:
> 
> +---------+
> |landscape|
> |         |
> +---------+
> 
> my output looks like this:
> 
> +----+
> |land|
> |    |
> +----+
> 
> In other words, it is incorrectly rotated, and it is cropped.
> 
> I have discovered that the job document is still in landscape format
> (i.e. the width is larger than the height) when it reaches foomatic-rip.
> 
> Comparing this with a correctly-working queue that uses CUPS Raster, I
> see a similar situation when the job document reaches pstoraster:
> 
>   pdftops ( -> pstops ) -> pstoraster -> ...
> 
> In this situation, however, pstoraster generates raster output that is
> in portrait format, i.e. the height is larger than the width.  I think
> this is because it has examined the PPD and found that the output must
> be rotated in order to match one of the listed page sizes.
> 
> So my question is:
> 
> ***
> Must application/vnd.cups-postscript documents (i.e. the output of
> pstops) be in any particular orientation?
> ***
> 
> If they should be in an orientation matching a page size listed in the
> PPD, pstops is not doing that in my case.
> 
> Conversely, if no particular orientation can be assumed, foomatic ought
> to be rotating its input so that it matches a page size listed in the
> PPD, and it is not doing that in my case.
> 
> Which filter is at fault?
> 
> Thanks,
> Tim.
> */

Tim,

my first suspicion is the pdftops filter. From my experience with various 
cups versions (1.3.5 to 1.4.5 on Mac os X, SuSE 11.1 and peppermint one) I 
think both lines of pdftops filters (xpdf based and poppler based) have 
difficulties with PDFs the MediaBox (or CropBox, if present) of which has a 
width greater than height, i.e. a landscape page format by dimensions.
Moreover, the pstops filter seems to ignore this sort of page geometry 
altogether - it is sort of too affine to level 1 PostScript.

In case of the cups-raster railway, I recently published a filter, 
gstoraster, which account for this with both PDF and PS input and skips the 
pstops filter.

Helge