Comment 11 for bug 820820

I forwarded this to the upstream author. Here is his response:

    So a PDF->PostScript->PDF path is more than awkward.

The reasons for not skipping this step are known to you (it will severly impede the functionality of CUPS-PDF). Furthermore, once again, CUPS-PDF is not meant for processing PDF-input (i.e., it is not meant to be a PDF-manipulation tool).

    1. Use the CUPS options for N-up, reverse order, selected pages, scale-
    to-fit, ... They are all executed by the pdftopdf CUPS filter and user-
    accessible by the GTK printing dialog (later by the Common Print
    Dialog).

Those apply to the pdftopdf filter of CUPS. As for pdftopdf: see above.

    2. Enhance the pdftopdf CUPS filter by adding more page manipulations to
    it (patches welcome). This would offer these page manipulations also to
    queues which print to real printers.

I am certain that pdftopdf can be used as a great PDF-manipulation tool - but once again: that is not what CUPS-PDF is made for.

    3. Use pdftk instead of Ghostscript in the cups-pdf backend.

And once more: with pdftk one can modify PDFs. CUPS-PDF is made to convert non-PDF to PDF.

So, what is being suggested here is to have a tool that can drop printjobs to defined directories as CUPS-PDF does but does not convert PS to PDF but manipulates PDF instead.

Just for your understanding why I am so adamant about CUPS-PDF not relying on PDF-input: I never developed CUPS-PDF as "latest-and-greatest"-tool, but as a tool we employ in our labs with several hundert students/workers and a very diverse IT-infrastructure. With respect to printing, PS really IS a common ground to start from. PDF is entirely unknown to several of our installations.