cups-pdf should support the PDF printing workflow
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cups-pdf (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: cups-pdf
cups-pdf consists of a PPD file and a CUPS backend. The backend assumes all input data being PostScript and converts the data to PDF. The resulting file is dropped in the ~/PDF subdirectory of the home directory of the sender of the job. The PPD file does not contain any cupsFilter line which makes CUPS assuming that PostScript with embedded printer-specific option settings is expected to be sent to the backend.
All this works fine with the virgin upstream CUPS which performs a PostScript-based printing workflow. All input files are converted to PostScript, then passed through the pstops filter to do page management (N-up, reverse order, selected pages, ...) and embed the PostScript commands for the option settings, and after that the output goes to the backend (in case of PostScript printers or cups-pdf) or to a printer driver filter.
In Ubuntu and Debian CUPS has extra filters and changed filter rules so that a PDF-based printing workflow is implemented. See
http://
Here all incoming files are converted to PDF and the the pdftopdf filter does the page management. If the PPD accepts PDF by an appropriate cupsFilter line the output gets passed through to the printer driver or to the backend. In case of a PPD without cupsFilter line (like the one of cups-pdf) or only with cupsFilter lines taking PostScript as input format, CUPS calls the cpdftocps filter (the "PostScript printer driver") after pdftopdf filter, so that there is PostScript in the end. This means that in the worst case the following happens for cups-pdf:
Application --PostScript--> pstopdf --PDF--> pdftopdf --PDF-->
cpdftocps --PostScript--> cups-pdf --PDF--> ~/PDF
So we go forth and back between PDF and PostScript several times.
Now I suggest to add support for the PDF printing workflow to cups-pdf. This can be implemented in a very simple way:
1. Let the cups-pdf backend accept both PostScript and PDF as input. Let it check whether the incoming data starts with the PDF magic string ("%PDF"). If so, do not any conversion, simply drop the file in ~/PDF. If not, convert the file to PDF as before.
2. Let the PPD file tell CUPS that the backend accepts both PostScript and PDF. Add the lines
*cupsFilter: "application/
*cupsFilter: "application/
to the PPD file.
Now on Debian and Ubuntu the following will happen:
Application --PostScript--> pstopdf --PDF--> pdftopdf --PDF-->
cups-pdf --PDF--> ~/PDF
The file is converted to a different format only once and not three times. With newer applications it gets even simpler:
Application --PDF--> pdftopdf --PDF--> cups-pdf --PDF--> ~/PDF
On all other distros which did not accept the PDF printing workflow yet, nothing gets more complicated, all works as before.
This bug was fixed in the package cups-pdf - 2.5.0-2ubuntu2
---------------
cups-pdf (2.5.0-2ubuntu2) karmic; urgency=low
* debian/ patches/ 65_cups- pdf-support- pdf-workflow. patch: Added support local/apport- hook.py, debian/rules: Added apport hook (LP: #338442).
for the PDF printing workflow. PPD changed to let the backend accept
PDF input. Backend simply drops input data in the destination file
if it is already PDF (LP: #385709)
* debian/postinst: Added automatic update of the PPD files of already
existing print queues.
* debian/postinst: Removed code for directly editing CUPS config files if
CUPS is not running. CUPS is running anyway when debian/postinst is
executed, as the package depends on the cups package.
* debian/
-- Till Kamppeter <email address hidden> Tue, 16 Jun 2008 11:32:30 +0200