Discussion:
Auto-detecting PDF orientation for auto-rotation
Kai Hendry
2013-03-20 05:21:01 UTC
Permalink
Hi there,

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.
Loading Image...

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?

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. This is what the PPD looks like:
http://s.natalian.org/2013-03-20/Virtual_PDF_Printer.ppd

How do I modify it so that PDFs are auto-rotated depending on their orientation?


I did also notice https://github.com/smilingthax/pdfautorotate though
again I'm not sure how to integrate this.

Thanks for any pointers in advance,
Johannes Meixner
2013-03-20 09:18:16 UTC
Permalink
Hello,
Post by Kai Hendry
I am looking for a solution whereby PDFs are auto-rotated.
Shouldn't the CUPS printing option "-o fit-to-page" do it?

See "Scaling to Fit" for CUPS 1.5 at
http://www.cups.org/documentation.php/doc-1.5/options.html
and for CUPS 1.6 at
http://www.cups.org/documentation.php/doc-1.6/options.html

For testing you may do the following:

Create two PDFs in portrait and landscape orientation:
-------------------------------------------------------------------
$ echo "portrait" \
| a2ps -1 -M a4 -o- \
| ps2pdf -sPAPERSIZE=a4 - /tmp/portrait.a4.pdf

$ echo "landscape" \
| a2ps -1 -r -M a4 -o- \
| ps2pdf -sPAPERSIZE=a4 - /tmp/landscape.a4.pdf
-------------------------------------------------------------------
(ps2pdf is /usr/bin/ps2pdf from Ghostscript)

Verify that the PDFs are actually portrait versus landscape:
-------------------------------------------------------------------
$ gs -sDEVICE=bbox -dBATCH -dNOPAUSE /tmp/portrait.a4.pdf 2>&1 \
| grep '%BoundingBox'
%%BoundingBox: 23 23 572 815

$ gs -sDEVICE=bbox -dBATCH -dNOPAUSE /tmp/landscape.a4.pdf 2>&1 \
| grep '%BoundingBox'
%%BoundingBox: 23 23 819 568
-------------------------------------------------------------------

Print them with and without "-o fit-to-page":
-------------------------------------------------------------------
$ lp -d <queue_name> /tmp/portrait.a4.pdf

$ lp -d <queue_name> /tmp/landscape.a4.pdf

$ lp -d <queue_name> -o fit-to-page /tmp/portrait.a4.pdf

$ lp -d <queue_name> -o fit-to-page /tmp/landscape.a4.pdf
-------------------------------------------------------------------

When you print to a real PostScript printer it may depend
on the printer's internal settings whether or not the
printer itself may autorotate pages to fit them on the paper.

Also the filters/drivers in the printing system that convert PDF
to PostScript and/or to other printer-specific data (e.g. PCL)
may autorotate pages, see Till Kamppeter's initial description in
https://bugs.linuxfoundation.org/show_bug.cgi?id=1080
----------------------------------------------------------------------------
Note that in a full printing workflow the bug often gets overlooked
as some printer drivers (Like the CUPS Raster output device of Ghostscript)
or built-in PostScript and PDF interpreters of printers rotate the PDFs
by themselves.
Other drivers, like the "ljet4" driver of Ghostscript do not rotate
the page content to fit onto the page.
----------------------------------------------------------------------------


Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany
HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer
Douglas Kosovic
2013-03-20 09:18:26 UTC
Permalink
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
Kai Hendry
2013-03-20 09:57:23 UTC
Permalink
Post by Douglas Kosovic
You didn't mentioned which version of cups (and cups-filters for late Linux distributions) you are using.
curl -s -L http://build.webconverger.org/latest.txt | grep cups

cups 1.5 basically :-)



I am eager to try your suggestions. However I've managed to b0rk
Virtual_PDF_Printer on my cups 1.6.2 server and I can't get
Webconverger CUPS 1.5 client.conf to talk to my Arch cups 1.6.2 server
anymore. Will need to look into this again tomorrow when I'm fresh.



Thanks for your help!

Loading...