PDF instead of PostScript as standard print job transfer format
One of the decisions which was made on the OSDL Printing Summit in Atlanta in 2006 and widely accepted by all participants was to switch the standard print job transfer format from PostScript to PDF. This format has many important advantages, especially
* PDF is the common platform-
* Portable
* Easy post-processing (N-up, booklets, scaling, ...)
* Easy Color management support
* Easy High color depth support (> 8bit/channel)
* Easy Transparency support
* Smaller files
* Linux workflow gets closer to Mac OS X
Most important here is the post-processing. In contrary to PostScript, one can easily distinguish in every PDF file which part of the data belongs to which page. So one can easily take the pages apart and do things like printing selected pages, 2, 4, ... pages per sheet, even/odd pages for manual duplex, scaling, ... PostScript files must be strictly DSC-conforming to allow this kind of page management. By using PDF we assure that page management always works.
The switchover to PDF as standard print job format is work in progress. For CUPS appropriate filters are already available in the Subversion repositories of the OpenPrinting Japan SourceForge site (http://
The foomatic-rip filter was made PDF-ready by Lars Uebernickel due to an internship at OpenPrinting, mentored by Till Kamppeter and funded by the Linux Foundation.
The texttopdf filter to print plain text files and the pdftoijs filter to couple IJS plug-in drivers (like HPLIP or Gutenprint) with a PDF renderer got implemented by Tobias Hoffman as a Google Summer of Code project, mentored by Hin-Tak Leung, author of various drivers for printers with proprietary protocols (so-called winprinters or GDI printers).
All these filters got packaged up and uploaded into Intrepid in the last weeks. This way the PDF workflow got implemented on the printing system/server side. To complete it, applications should be modified to emit PDF instead of PostScript when the document is sent to the printer. But due to the capability of CUPS to convert PostScript input to PDF the change of the applications is not urgent. Especially we will get the page management already working.
Blueprint information
- Status:
- Complete
- Approver:
- Henrik Nilsen Omma
- Priority:
- Undefined
- Drafter:
- Till Kamppeter
- Direction:
- Needs approval
- Assignee:
- Till Kamppeter
- Definition:
- Review
- Series goal:
- Proposed for intrepid
- Implementation:
-
Implemented
- Milestone target:
-
intrepid-alpha-4
- Started by
- Henrik Nilsen Omma
- Completed by
- Till Kamppeter
Related branches
Whiteboard
heno 2008-05-28: Milestoning for Intrepid Alpha 2 as it's well under way, though it will need a formal review.
pitti 2008-05-29: Concept and design looks convincing and sound to me. However, the implementation section is still very thin. In particular, I am interested in seeing which changes need to be made to cups itself to provide full backwards compatibility with previous releases (i. e. receiving PostScript), while also accepting PDF as input format without converting it back and forth again. With this, the client-side parts of the specs can be implemented independently and do not block each other. We also need to ensure that third-party/legacy applications which only emit PS will continue to work forever. Please add some details of the cups changes to the implementation section and point out the backwards compatibility in the 'migration' section. Thanks!
tkamppeter 2008-05-31: Details added.
pitti 2008-06-02: It still does not explain what changes we need to make in cups? AFAIK it still uses PostScript internally in the current version?
tkamppeter 2008-06-02: List of filters and rules files and also report about coding state added
tkamppeter 2008-07-17: As of the OpenPrinting Meeting on the LF Symposium in Tokyo on July 8 th OpenPrinting Japan workgroup will prepare packaging-friendly PDF filters not containing the source code of CUPS and Poppler any more. These will get packaged for Intrepid soon. Hin-Tak Leung, mentor of the GSoC student on texttopdf and pdftoijs reported that they work on preparing the filters to get packaged currently.
tkamppeter 2008-09-25: Implementation progress:
DONE:
- foomatic-rip 4.0 accepts PDF
- foomatic-rip 4.0 internal conversion PDF to PS if PPD has options which embed PS code (or driver is otherwise not PDF-capable)
- foomatic-db-engine 4.0: Add cupsFilter line for PDF to the PPDs, allow PDF-specific command line in XML files
- foomatic-db: Modified driver options so that as many drivers as possible can take directly PDF as input.
- CUPS has PDF filters imagetopdf, texttopdf, pstopdf, pdftopdf, pdftoraster, pdftoijs, cpdftocps
- Adjusted cost factors of the CUPS filters so that PDF-based filter chains get preferred
- Driver packages which are prepared for PDF (usually by cupsFilter line for PDF in the PPDs): hplip, foo2zjs, m2300w, pxljr, Ricoh PPDs (openprinting-
- Drivers which do not need to be changed: min12xxw, splix, gutenprint, cups-included
- KDE/Qt apps send PDF when printing
- Most GNOME/GTK apps send PDF when printing (bug 258421)
- Made CUPS test page work correctly (bug 263049)
TODO:
- Several GNOME/GTK apps need to be switched to send PDF when printing individually
- OpenOffice.org needs to send PDF when printing (Upstream bug: http://
The server part of the PDF printing workflow is now completed and all print jobs are processed with a PDF-centered workflow now. What is missing is only that many applications, especially GNOME/GTK and OpenOffice.org send print jobs still in PostScript format. But this does not break anything, CUPS converts the PostScript input immediately and continues processing on PDF.
tkamppeter 2008-10-23: Closing as implemented. Nearly everything for the PDF printing workflow is done. Only missing pieces are that some applications still send PostScript print jobs. We will not patch these applications to switch over to PDF but rather let the switchover come with the upstream development.
