[cups.general] Auto-detecting PDF orientation for auto-rotation

[Douglas Kosovic]

Hi Kai,

> I have a customer whose users print a lot of PDFs, however those users cannot
> be expected to manually set the orientation of the Print dialog.
> https://f.cloud.github.com/assets/765871/274044/58358202-9047-11e2-
> 8915-397269186484.png
> 
> So I am looking for a solution whereby PDFs are auto-rotated.
> 
> Tbh I'm not entirely sure who should be doing the auto-rotation transform.. The
> PDF viewer? CUPS itself? The individual PPD driver? The printer itself?

You didn't mentioned which version of cups (and cups-filters for late Linux distributions) you are using.

> After Googling a bit, it seems that the cups-filter /usr/lib/cups/filter/pdftopdf
> might be upto the job. However IIUC, the PPD needs to have a rule to use this
> filter?

> I'm using a cups-pdf configured printer and I'm printing a landscape PDF from
> epdfview. 

I'm not familiar with epdfview, is it sending PDF or PS to CUPS? If it's PDF, the CUPS filter graph would be something like:
   PDF input -> pdftops -> pstops -> cups-pdf
Or :
   PDF input -> pdftopdf -> pdftops -> pstops -> cups-pdf

Unless you are using a modified or beta version of cups-pdf which just passes though the PDF without processing, there will be intermediate PS conversion. I think the the ideal filter graph would be the following :
   PDF input -> pdftopdf -> cups-pdf

At my site, 99% of the documents sent to CUPS are PDF

> Thanks for any pointers in advance,

If you are able to, I would try upgrading to a late or latest version of cups-filters (i.e. QPDF based pdftopdf filter and pdftops filter with Ghostscript 9.0x renderer). It solved a lot of orientation issues we were having including documents sent by users that intentionally changed orientation multiple times within a document. The following is an extract from the cups-filters README on how to set the renderer for pdftops :

----
Be sure that the pdftops filter is using Ghostscript and not Poppler.

    1. Selection of the renderer: Ghostscript, Poppler, or Adobe Reader

    Ghostscript has better color management and is generally optimized
    more for printing. Poppler produces a PostScript which is
    compatible with more buggy built-in PostScript interpreters of
    printers and it leads to a somewhat quicker workflow when
    graphical structures of the input PDF has to be turned into
    bitmaps. Adobe Reader is the PDF renderer from Adobe, the ones
    who created PDF and PostScript.

    The selection is done by the "pdftops-renderer" option, setting it
    to "gs", "pdftops", or "acroread":

    Per-job:           lpr -o pdftops-renderer=pdftops ...
    Per-queue default: lpadmin -p printer -o pdftops-renderer-default=gs
    Remove default:    lpadmin -p printer -R pdftops-renderer-default

    By default, pdftops uses Ghostscript if this does not get changed
    at compile time, for example by the Linux distribution vendor.
----



Cheers,
Doug