From The Linux Foundation
Jump to: navigation, search

Implementation of Printing Infrastructure

Here is a list of pieces of printing infrastructure which needs to be implemented soon. Some of these pieces the Linux Foundation plans to support financially, but unfortunately, we cannot sponsor all the work. So we are very grateful for any volunteer to take one or more of these projects and for sponsors who will contribute either the money that we can pay someone to do a task or providing the manpower for work getting done.

Every financial contribution to the Linux Foundation will be fully dedicated to the project(s) which you like to support.

Many things need to be implemented in CUPS, especially for the planned printing requirements in LSB 3.2. Here the Linux Foundation plans to pay Mike Sweet for. He is the author of CUPS. For all CUPS and non-CUPS tasks not needed for LSB 3.2 the Linux Foundation will look into possible financial support after release of LSB 3.2.

We need especially sponsors for the implementation of JTAPI, so that it gets implemented in time for LSB 4.0.

We are hiring students/interns!

To implement the use of the PDF data format as standard print job transfer format (instead of the currently used PostScript) we are hiring students or interns for the following two projects:

  • PDF printing workflow with foomatic-rip
  • Modularization of built-in GhostScript drivers into an OpenPrinting Vector (OPVP) driver

If you are interested, please contact Till Kamppeter, Manager OpenPrinting (till dot kamppeter at gmail dot com).

There are no restrictions on where you live. You can work with us from home, using the internet.


A. PDF printing workflow with foomatic-rip

One of the decisions which was made on the OSDL Printing Summit in Atlanta last year 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-independent web format for printable documents
  • 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

Very many printer drivers use the universal print filter/RIP (Raster Image Processor) wrapper foomatic-rip, which is a part of the OpenPrinting database environment (Foomatic) and as Foomatic is a standard part of all modern Linux distributions it is available everywhere. foomatic-rip is also part of SUN's Solaris and used with the LP printing system there.

The switchover to PDF as standard print job format is work in progress. For CUPS appropriate filters are already under development and first versions are available in the Subversion repositories of the OpenPrinting Japan SourceForge site.

foomatic-rip currently only accepts PostScript (and for non-CUPS spoolers also text and images, but they are converted to PostScript before further processing) as input format. foomatic-rip does certain pre-processing of the PostScript. It reads out embedded option setting information, so that these options can be applied outside the RIP (GhostScript), like on the command line of the RIP or of an additional filter or as PJL commands directly in the printer. And it also embeds option settings into the PostScript data stream if the options are supplied by the foomatic-rip command line (spooler got them with a job ticket or other meta data which accompanied the job).

Goal of this project is to make foomatic-rip accepting PDF as well. It should do the same read-out and embedding of option settings, it should distinguish whether the input is PostScript or PDF and do the right work then. The PPD files should be changed to reflect the support for both PostScript and PDF andalso if needed the Foomatic database expanded to generate driver command lines for both PostScript and PDF workflows. It should also get optimized in system resource consumption, perhaps rewritten in C.

What is needed: Knowledge in Perl and also some knowledge in XML and in the Linux/Unix printing workflow. Some knowledge in C and PostScript would be nice.

B. Modularization of built-in GhostScript drivers into an OPVP driver

To turn the above-mentioned switchover from PostScript to PDF as standard print job transfer format we need to make all printer drivers working with arbitrary renderers (for example libpoppler for PDF). This is easy to implement for most modern drivers which are IJS plug-ins, separate filters, CUPS raster drivers, and OpenPrinting Vector drivers, but for the drivers built into GhostScript this is not yet possible.

Therefore we want to modularize the built-in GhostScript drivers into something which plugs into the renderer. A side effect of this is also the easier maintainability of GhostScript and of the drivers, especially of built-in drivers from third parties.

As there are some high level/vector devices the suggest interface is the OpenPrinting Vector framework. The implementation should be some kind of glue code module which has on one end the OPVP interface to get the data from the renderer and on the other end the internal API of GhostScript to couple to the original GhostScript driver code. Compiling this should result in one or more OPVP drivers with the same functionality of the built-in GhostScript drivers.

Goal of this project is to implement and test this framework and it would be a plus to also do the needed modification of the Foomatic data to generate the PPDs for the modularized drivers.

Knowledge in C programming is required. Great is also knowledge in PostScript and the Linux/Unix printing workflow.


These are the most urgent action items we meed from Mike Sweet, author of CUPS. They are listed in priority order. The first two are most urgent for LSB 3.2, therefore Linux Foundation will pay Mike Sweet for doing them as soon as possible.

1. LSB 3.2 action items (note here that Todd Fujinaka was reassigned and does not work for LSB or printing any more):
    • Need specification
    • Need to make sure existing tests cover the interfaces we include
  • CUPS Raster API
    • Need specification
    • Need to make sure existing tests cover the interfaces we include

See also

2. Adding facility to the web interface to automatically look up and download PPDs and drivers from the OpenPrinting database. This makes it easier to demo our service of downloadable distribution-independent driver packages
3. CUPS support for using PDF as standards print job transfer format (pdftopdf filter implementation under work by Japanese PCM team)
4. Implementation of PAPI and JTAPI in CUPS



Norm Jacobs and Wendy Phillips from Sun work on the PAPI implementation

Man power/funding for implementation of PAPI in CUPS is needed.


Implementation did not start yet. We need man power/funding.

Contacts: Claudia Alimpich, Ira McDonald