[cups.development] orientation-requested regression for pdf files?

[Jon Peatfield]

On Tue, 8 Apr 2008, Kevin Hamilton wrote:

> I just moved several applications from a server running cups 1.2.4 to a 
> server running cups 1.3.6, and found that my orientation-requested 
> option is being ignored.
>
> The command my application is attempting to run, is: lpr.cups 
> -Pprintername -o orientation-requested=6 -o Duplex=DuplexTumble filename
>
> Whether I pass orientation-requested=3 or orientation-requested=6, I 
> always get portrait output at the printer, never reverse-portrait which 
> is what I need.
>
> However, it is only ignored when the document to be printed is a pdf 
> file, if the file is an ASCII text document, then it rotates as 
> expected.
>
> Looking through the bug tracker, I think, but am not certain, that it is 
> a regression introduced in STR2348 http://www.cups.org/str.php?L2348.
>
> Any thoughts or help would be much appreciated.

Back in December I found a similar thing with cups-1.3.4 in that the 
pdftops seemed to perform the requested rotation (90 degrees in my tests), 
but then pstops did it again (to 90 became 180, 180 became 360 etc).

This is what Michael R Sweet said:

> The standard pdftops included with CUPS embeds a cupsRotation comment
> that tells pstops what orientation/rotation has been performed.
>
> If you use a different pdftops filter, that information is lost and
> you can get double-rotation.

And I commented:

> In case my previous builds of pdftops were damaged I just rebuilt 
> pdftops from the clean (unpatched at all) cups-1.3.4 sources.
> 
> Feeding it a pdf file which is landscape (US-Letter as it happens while 
> our printers all have A4 set as their default papersize), I get 
> '%cupsRotation: 0' in the postscript output irrespective of what I set
> orientation-requested to (or not set).

[ is the cups-dev mailing list archived anywhere? ]

I currently 'solve' this by having a wrapper round pdftops which removes 
the orientation-requested option from the command-line so it does nothing 
wrt rotations letting pstops do the work.

For us that seems to do the job.  I've not yet tested if things are 
different in newer versions of cups - I know that the pdftops code was 
updated in the meantime (I *think* it no longer is based on xpdf source 
but poppler (an xpdf fork) instead).

I'm currently in the process of testing builds of cups-1.3.7 but havn't 
got far enough to risk replacing our working setup (people seem to get 
upset every time I break printing... :-)  Hopefully in the next few days 
I'll be able to see if the same problem happens there or not.

[ btw the %cupsRotation stuff was introduced to fix STR #2149, see 
http://www.cups.org/str.php?L2149 ]

-- 
Jon Peatfield,  Computer Officer,  DAMTP,  University of Cambridge
Mail:  jp107 at damtp.cam.ac.uk     Web:  http://www.damtp.cam.ac.uk/