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
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://sourceforge.jp/projects/opfc).
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 Ubuntu Intrepid in the last weeks. This way the PDF workflow got implemented on the printing system/server side.
To complete the PDF printing workflow, 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.
If you want to test the PDF printing workflow without changing your system, try Ubuntu Intrepid. Live CDs are available.
CUPS needs the following additional filters to make print job being processed in a PDF printing workflow, with page management being done by pdftopdf and not pstops any more:
Most of these filters (all except pstopdf, pdftoraster, and cpdftocps) were proposed to be a part of the upstream CUPS package and therefore they are available in a convenient tarball. The tarball adds everything necessary to include the filters in the CUPS source tree and make them being built and installed together with CUPS.
To add the filters to CUPS, download the tarball, uncompress it, and add the filters to the CUPS source tree as described in the included README file.
The filters in the above-mentioned filter kit are Poppler-based, due to Poppler's more flexible API. For pdftoraster we use Ghostscript as it is much more optimized for printing and is also more advanced in terms of color management. Unfortunately, GPL Ghostscript 8.63 has a bug which prevents Ghostscript's CUPS Raster output device ("cups") from working with PDF input data. This is fixed in Ghostscript's subversion repository and so in GPL Ghostscript 8.64 the bug will be fixed. For Ghostscript 8.63 a patch is available. With this patch applied this Ghostscript-based pdftoraster filter can be used. Compile the filter with
gcc -I/usr/include/cups -o pdftoraster -lcups -lcupsimage pdftoraster.c
and copy the resulting binary file pdftoraster into /usr/lib/cups/filter/. Download also pstoraster.convs and put it into the /etc/cups/ directory. Make it world-readable. The filter is also uploaded into the Subversion repository of Ghostscript, so it will also be standard part of GPL Ghostscript 8.64.
The remaining filters, pstopdf and cpdftocps, are simple scripts which can be downloaded here. Make them world-executable and put them into the /usr/lib/cups/filter directory. Download also the conversion rule files pstopdf.convs and cpdftocps.convs from the same place and copy them into the /etc/cups directory. The files must be world-readable.
The imagetopdf and pdftopdf filters are written by Koji Otani (BBR Inc., Japan, sho at bbr dot jp) and hosted at [http://sourceforge.jp/projects/opfc the OPFC project at SourceForge Japan). He has also written a Poppler-based pdftoraster filter.
The texttopdf and pdftoijs filters are written by Tobias Hoffmann (th55 at gmx dot de) as a Google Summer of Code project, mentored by Hin-Tak Leung (hintak_leung at yahoo dot co dot uk). They are also hosted at [http://sourceforge.jp/projects/opfc the OPFC project at SourceForge Japan).
The pstopdf filter was originally written by Robert Sander (robert dot sander at epigenomics dot com) and improved for the PDF printing workflow by Johan Kiviniemi (debian at johan dot kiviniemi dot name).
The cpdftocps filter converts CUPS PDF (PDF which was passed through the pdftopdf filter) to CUPS PostScript (PostScript which was passed through pstops, expected as input by native PostScript PPDs without *cupsFilter lines or legacy PPDs). It is a script which calls the CUPS filter pdftops to convert to PostScript and then pstops to insert the PostScript code of the PPD options. As the page management options of CUPS were already applied by pdftopdf, on the call of pstops from within this filter these options are filtered out of the command line. This filter can be considered as a "PostScript printer driver", as it generates the PostScript needed by the PostScript printers. The cpdftocps filter is written by Johan Kiviniemi (debian at johan dot kiviniemi dot name).
The Ghostscript-based pdftoraster filter is written by Till Kamppeter, who also made the patch to fix Ghostscript's CUPS Raster output device. Note that in contrary to pstoraster this filter is written in C. This is need to make use of the CUPS libraries to read out the PostScript code defined in the PPD file which is supposed to get inserted into the PostScript input data stream in order to let Ghostscript generate the correct CUPS Raster data according to the option settings supplied by the user. This is not possible with PDF input data. The filter then converts the PostScript code into equivalent command line options for the Ghostscript call and then calls Ghostscript. pstoraster only needs to call Ghostscript, as pstops has already embedded the PostScript code in the PostScript input stream then. Therefore pstoraster can be a simple shell script. As pdftoraster does not modify the input data stream, it works as well with a PostScript input data stream.
Every file format conversion rule in CUPS (in the /etc/cups/*.convs, also *cupsFilter lines in the PPD) files has not only an input and an output format and a filter name, but also a numerical cost factor. The cost factors of each filter chain computed by CUPS will be added and if there is more than one possible filter chain for a job, CUPS takes the "cheapest" one.
To make sure that the PDF-based way is always preferred, we raise the cost factor of the pstops filter from 66 to 100 in /etc/cups/mime.convs:
sed -i -r -e '/\spstops$/ { s/66/100/ }' /etc/cups/mime.convs
All other relevant conversion rules are in the conversion rule files coming with the new CUPS filters and their cost factors are already low enough.
Also with PDF-centric printing Ghostscript is a central part of the printing infrastructure, as it takes PDF as well as PostScript as input format. Especially all the built-in drivers of Ghostscript can be continued to be used.
In Ghostscript many bugs on PDF renderiung where fixed recently. Therefore use the newest Ghostscript version to get best results.
foomatic-rip 3.x does not understand PDF as input format. This feature was added as a principle feature of foomatic-rip 4.0. foomatic-rip 4.0 feeds PDF directly into the Ghostscript process which renders the input into printer's format together with the driver, at least if Ghostscript is called directly in the beginning of the rendering command line and no option requires PostScript commands to be inserted into the data stream to get executed. Otherwise, foomatic-rip 4.0 converts the input into PostScript at first.
The new foomatic-db-engine has extensions for the PDF workflow in its PPD generator. Especially PPDs are generated with the lines
*cupsFilter: "application/vnd.cups-postscript 100 foomatic-rip" *cupsFilter: "application/vnd.cups-pdf 0 foomatic-rip"
instead of
*cupsFilter: "application/vnd.cups-postscript 0 foomatic-rip"
now, so that foomatic-rip accepts PDF as input format with this PPD. It also accepts the new "<prototype_pdf>...</prototype_pdf>" tag in the "<execution>" section of Foomatic driver XML files to allow specifying a separate command line prototype for PDF input. From this tag the PPD generator creates the new "*FoomaticRIPCommandLinePDF" keyword in the PPD files.
Download foomatic-rip 4.0 from the BZR repository via
bzr branch http://bzr.openprinting.org/devel/foomatic-filters-devel cd foomatic-filters-devel ./make_configure rm -rf autom4te.cache
If you need a source tarball for packaging, make the tarball of the foomatic-filters-devel directory now.
Build the package with
./configure --prefix=/usr make
Install it with (must be run as root):
make install
Download foomatic-db-engine 4.0 from the BZR repository via
bzr branch http://bzr.openprinting.org/devel/foomatic-db-engine-devel cd foomatic-db-engine-devel ./make_configure rm -rf autom4te.cache
If you need a source tarball for packaging, make the tarball of the foomatic-db-engine-devel directory now.
Build the package with
./configure --prefix=/usr make
Install it with (must be run as root):
make install
The data for generating PPD files in the OpenPrinting database was adapted to the PDF printing workflow by replacing all options which control Ghostscript and Ghostscript-based printer drivers with PostScript commands to be inserted into the input data stream by options which add command line arguments to the Ghostscript and/or driver command line. This way foomatic-rip feeds PDF input directly into Ghostscript and all available user-settable options for the driver still work as before.
Download the current foomatic-db from the BZR repository via
bzr branch http://bzr.openprinting.org/devel/foomatic-db cd foomatic-db ./make_configure rm -rf autom4te.cache
If you need a source tarball for packaging, make the tarball of the foomatic-db directory now.
Build the package with
./configure --prefix=/usr make
Install it with (must be run as root):
make install
There are many PPD files on a typical system which are not generated by Foomatic, but they use also foomatic-rip and so they (and their corresponding drivers) can be used with PDF input data. These PPDs come with driver packages, or as manufacturer-supplied PPDs.
To convert them all to accept PDF run the following commands:
cd /usr/share/ppd # (or cd /usr/share/cups/model) find . -name "*.ppd" | xargs perl -p -i -e \ 's,^\*cupsFilter:\s*\"application/vnd.cups-postscript\s+0\s+foomatic-rip\",*cupsFilter: "application/vnd.cups-postscript 100 foomatic-rip"\n*cupsFilter: "application/vnd.cups-pdf 0 foomatic-rip",' for f in `find . -name '*.ppd.gz'`; do gzip -cd $f | perl -p -e \ 's,^\*cupsFilter:\s*\"application/vnd.cups-postscript\s+0\s+foomatic-rip\",*cupsFilter: "application/vnd.cups-postscript 100 foomatic-rip"\n*cupsFilter: "application/vnd.cups-pdf 0 foomatic-rip",' | \ gzip -9 > $f.tmp; rm $f; mv $f.tmp $f; done
For KDE and Qt applications you only need a not too old Qt (4.x) and CUPS 1.2.x or newer. Then Qt emits print jobs in PDF format. So for these applications the PDF printing workflow is already upstream reality.
GTK and GNOME did not switch over to PDF yet. You can apply a patch to GTK to get at least some GTK/GNOME applications to emit print jobs in PDF.
OpenOffice.org, Firefox and Thunderbird still need to get switched over. Patches welcome.
If not all applications are sending PDF to CUPS, you will still get printouts and you will already get the advantages of doing page management on a PDF data stream. CUPS simply converts incoming PostScript using the pstopdf filter before doing any further step.
The reports listed here are once feature requests to several free software projects for implementing the PDF printing workflow and also bug reports about problems concerning the PDF printing workflow.