Main GSoC Linux Foundation page: How to apply, deadlines, other workgroups, ...

Important: We protect the e-mail adresses of our mentors and mailing lists against spam bots. Please replace all occurences of “ at ” and “ dot ” by “@” and “.” resp.

Mailing list: printing-architecture at lists dot linux-foundation dot org

IRC: #openprinting on Freenode

OpenPrinting developer resources

Code License: See project descriptions

The cups-filters project at OpenPrinting (included in all Linux distributions using CUPS 1.6.x or newer) provides the filters needed to convert the print job output of desktop applications (usually PDF) into the printer's native language or into the universal CUPS/PWG-Raster format as input for a separate printer driver. It also provides the pdftopdf filter to apply page management (N pages per sheet, selected pages, even/odd pages for manual duplex, mirror for iron-on sheets, …) to the PDF data stream.

A central part to make this work is a PDF renderer and many of the filters are simply wrappers about a PDF renderer. Currently, cups-filters supports Ghostscript and Poppler as PDF renderer. With this project we want to add support for MuPDF as it is a more lightweight renderer made by Artifex, the printing specialists who already made Ghostscript. This is especially interesting for mobile devices with limited meomory, mass storage, and CPU resources.

The student will have to modify all filters which need a PDF renderer (pdftops, pdftoraster, pdftoijs, pdftoopvp, perhaps also pdftopdf) to add support for MuPDF without dropping the existing support for Ghostscript and Poppler. Switching between the renderers should be able at run time, to make binary packages of cups-filters suitable for systems of different form factors.

Mentors: Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till at linux dot com), Tobias Hoffmann (smilingthax at googlemail dot com), MuPDF developers TBD

Desired knowledge: C and/or C++ programming

Code License: MIT, GPL

MuPDF is a lightweight PDF renderer made by Artifex, the company behind Ghostscript. In contrary to Ghostscript, MuPDF is a pure PDF renderer. It does not contain a PostScript interpreter nor parts of it are written in PostScript. This makes it smaller, faster, and less resource-consuming, the ideal solution for mobile devices like tablets or smartphones.

On mobile devices printing will not be done with having tons of printer-model-specific drivers on the system. Once, they consume the limited mass storage space, and second, one uses the mobile device in several different local networks with different printers: At home, in the office, in a copy shop, … and one wants to use the printers which are available there, without installing drivers and setting up queues.

Therefore we want to have a system which automatically detects network printers and makes them available for local apps. To do so we restrict ourselves to printers with known, common languages: IPP Everywhere (Upcoming standard, PWG Raster and optionally some others) and PostScript, PDF, PCL 5c/e/6/XL (legacy standards). So MuPDF has to generate raster output for these languages, meaning raster embedded in the specifics of the language, and to avoid exhausting printer resources raster in small bands and no high-level output, even if the printer language is high-level.

Artifex will also work on this, but to get additional man power we are also opening this project for students.

Note that you have to assign copyright on your code to Artifex, as otherwise the code cannot be integrated in MuPDF.

This project can be split to be worked on by more than one student.

Mentors: MuPDF developers TBD, Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till at linux dot com)

Desired knowledge: C and/or C++ programming

Code License: GPL

The cups-filters project at OpenPrinting (included in all Linux distributions using CUPS 1.6.x or newer) provides the filters needed to convert the print job output of desktop applications (usually PDF) into the printer's native language or into the universal CUPS/PWG-Raster format as input for a separate printer driver. It also provides the pdftopdf filter to apply page management (N pages per sheet, selected pages, even/odd pages for manual duplex, mirror for iron-on sheets, …) to the PDF data stream.

One of the filters is pdftoopvp which is the interface between PDF (the standard print job format under Linux) and the OpenPrinting Vector high-level printer driver interface standard. This standard is currently used by several Japanese-market laser printers which do not use PostScript as it is usual in Europe and the US.

This filter currently only supports Poppler as PDF renderer and the connection between the filter and Poppler is rather awkward, copying parts of Poppler's source code and using unstable APIs of Poppler which change with newer Poppler versions. This makes maintaining the filter difficult for the Linux distributions.

The task for the student is here to once improve the interface with Poppler if possible and also add support for Ghostscript (would improve color management a lot) and MuPDF (would improve integration with mobile and embedded devices). The tasks can be split up over up to 3 students (Poppler, Ghostscript, MuPDF).

Mentors: Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till at linux dot com), Koji Otani, BBR Inc. Japan (sho at bbr dot jp), Ghostscript developers TBD

Desired knowledge: C and/or C++ programming

Code License: MIT

Foomatic serves now well for more than 10 years for integrating Ghostscript-based printer drivers with the printing environment under Linux (usually CUPS). Based on an XML database of printers, drivers, and user-settable driver options PPD (Postscript Printer Description) files are generated and used together with the universal print filter foomatic-rip. This way the user has access to all the driver's (and printer's) capabilities and Ghostscript is correctly called by the printing system to execute the print job.

This worked principally very well. One can really control all options of the printer drivers and even more sophisticated techniques, like CUPS' custom options (arbitrary numbers and strings as parameters) are supported.

But there are still two problems which did not get addressed due to the lack of manpower for implementing them:

Option setting conflicts

Often option settings do not work together, like printing double-sided on transparencies. PPD files use the “*UIConstraints: …” keyword to mark these conflicts so that in print dialogs and printer setup tools one cannot choose conflicting settings.

Foomatic has no functionality to define option setting conflicts and generate appropriate “*UIConstraints: …” keywords in the PPD files.

Printer compatibility classes

The other problem is that it is rather awkward to assign drivers and options to printers if there are very many similar, compatible models. Often one has to mention each printer explicitly in the driver and option XML entries.

Instead of needing to add many compatible printers to the drivers and to the constraints of options one could introduce compatibility classes. A compatibility class contains absolutely compatible printers, which means printers which work with the same drivers, the same options, and the same choices for the options. Then one can put the class name into the list of supported printers of a driver and also into the constraints of the options and so one avoids needing to insert tenth of printers everywhere. Especially there are many HP inkjets which are absolutely compatible to each other (around ten classes instead of 100 printers) and there are many clones of HP LaserJet printers.

What is needed for solving both problems is an extension to XML database, to the SQL representation of the database (for accelerated database access), and to the PPD file generator.

Mentor: Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till at linux dot com)

Desired knowledge: Perl programming, MySQL

Code License: GPL

CUPS has two mechanisms for on-the-fly-PPD generation to avoid the wasting of disk space by thousands o uncompressed (or slightly compressed) PPD files. One is to put an executable file into the /usr/lib/cups/driver/ directory which lists and generates PPD files on request, the other is using *.drv files in /usr/share/cups/drv, which contain the data for the PPDs in a simpler and more compact format.

The former method is deprecated upstream and can be removed in a future release of CUPS, especially also because the executables can get slow in some cases.

The latter is not yet supported by Foomatic and letting Foomatic support it is subject of this project idea.

The student's task is to create a utility which generates *.drv files from the whole database and/or from selected, printers, manufacturers, drivers, groups, …, depending on what the user requests.

Mentor: Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till at linux dot com)

Desired knowledge: Perl programming, perhaps also MySQL

Code License: GPL

cups-browsed is a daemon which comes with the cups-filters package from OpenPrinting and it discovers remote printers and automatically creates local print queues so that these remote printers are available locally. On desktop Linux distributions it is usually configured to only discover remote CUPS printers as they have a driver on the server side.

Mainly for printing on mobile devices without needing to set up anything cups-browsed can also discover IPP network printers with known page description languages (PostScript, PDF, PWG Raster, PCL) and set up print queues for them which accept PDF as input and turn data into the language needed by the printer. To have driver-less (no software or data files specific to the printer model) printing, these queues do not have a PPD (PostScript Printer Description) file which tells clients about printer-specific capabilities and user-settable options, meaning that if you print to such queues printing is done with everything on default (A4, one-sided, normal quality, …) as the print dialogs do not show any changeable options.

The student's task here is to create a backend for the GTK print dialog (the most used print dialog for desktop applications under Linux) which recognizes such print queues and polls the printer's capability list directly from the printer via IPP as soon as the user selects the printer and then set up the option panel of the dialog based on the found IPP options and choices and when printing send the job along with the user's settings and also static capabilities (like unprintable margins).

This way the user can simply print on an available network printer and make use of most of the printer's capabilities without needing to set up a print queue for the printer or have a driver for it.

Especially there will soon be printers following the IPP Everywhere standard from the Printing Working Group (PWG). These are IPP 2.x printers which understand at least PWG Raster but often also other languages and they inform clients about all their capabilities. These printers are designed for driver-less printing.

Mentors: Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till at linux dot com).

Desired knowledge: C programming

Code License: LGPL-2+

For desktop applications to know about the printer's capabilities, like available paper sizes, color/monochrome, resolution, output quality, margins, duples, … to correctly prepare the print jobs and also to show the user-settable options in the print dialog, print queues get assigned a PPD (PostScript Printer Description) file. This file is usually a static file delivered by the printer manufacturer or by the developers of third-party drivers together with the driver package.

The driver and especially the PPD file are software specific to the printer model, and for an operating system to support most printers important on the market, it has to ship thousands of PPD files and also get updates regularly. This is especially a problem for mobile devices with limited storage capacity for the operating system.

To avoid this we want to do driver-less printing, no printer-model-specific software or data files on the computer. And to do driver-less printing the Printing Working Group (PWG) has developed the IPP Everywhere standard. Printers following this standards are IPP 2.x printers which understand at least PWG Raster and often other common Page description languages (PostScript, PDF, PCL, TIFF, JPG, …). Thanks to IPP from these printers one can poll the capability information based on which one can auto-generate a PPD file.

There is already a basic implementation for this in the upcoming CUPS 2.1.x under development. The PPD generator needs to get improved, especially for UI constraints (conflicting settings, like duplex on transparencies) and choosable margin options (normal margins and borderless).

The student's task is to improve the PPD generator of CUPS, so that full-featured print queues for these printers can be generated fully automatically without need of a printer setup tool.

Mentors: Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till at linux dot com).

Desired knowledge: C programming

Code License: LGPL-2 and GPL-2

Job tickets are extended descriptions for print jobs. They tell which documents should be printed, on which type of paper, which resolution and quality, whether there should be sheets inserted between the documents, …, and even information like delivery address, payment, … A job ticket accompanies a print job from its submission to its delivery. Job tickets come from the professional printing world. In former times they were a paper form with instructions what everyone involved in the printing process has to do. Nowadays they are standardized files which are used by print servers, printers, and production printing machines.

IPP Everywhere is a next generation printing protocol by the Printing Work Group (PWG) and uses job tickets for all printing metadata. This makes job ticket handling vital for IPP Everywhere support. For IPP Everywhere the PWG has created the PWG Job Ticket format.

Libjtapi is OpenPrinting's reference implementation of the FSG's JTAPI standard. The FSG (Free Standards Group) was a predecessor to the Linux Foundation. The JTAPI standard defines an abstract api for producing and consuming job tickets. Thus Libjtapi can create Job Tickets and translate between job ticket formats provided a backend has been developed.

This project is to develop a Libjtapi backend for the PWG's job ticket format. This backend should be able to consume PWG tickets and produce PWG tickets.

Proposed Tasking:

Objective: Develop a Libjtapi backend for accepting, parsing, interpreting and translating PWG Job Tickets to LibJTAPI objects/attributes.

Approach: As Libjtapi is written in C89 this backend should be as well. PWG Job Tickets can come in either XML or JSON flavours and only one of these flavours must be supported. A JSON or XML parsing library written in C89 and relicensable under the EPL should be used. The backend may be written using internal Libjtapi helper functions or against the more verbose jtapi apis.

Code License: EPL

Coding Language: C89

Coding Document: In-line commenting must be sufficient to understand the flow and any section requiring extended understanding.

Operating System: Student’s choice – Linux, Windows, Mac, … (non-gui for either)

Interface: Command Line

Document: Minimum:

1. How to build the PWG Job Ticket backend.
2. How to build the test suite
3. How to run the test suite
4. Three example PWG job tickets that can be consumed and produced without data loss.

Mentor: Glen Petrie, Epson (glen dot petrie at eitc dot epson dot com)

Desired knowledge: C Programming

Adrian Johnson did a lot of the work needed to make cairo color managed. Finishing this work and getting the code upstream would allow us to simplify a lot of applications that use cairo. See http://cgit.freedesktop.org/~ajohnson/cairo/log/?h=color-space for the branch. Adrian has also patched Inkscape to use the new features, and that needs cleaning up and pushing upstream http://cgit.freedesktop.org/~ajohnson/inkscape/log/?h=color-space Also see http://lists.cairographics.org/archives/cairo/2012-July/023353.html and https://mail.gnome.org/archives/gimp-developer-list/2012-August/msg00084.html for more details.

Expectations: The cairo and inskcape code is pushed upstream with any required modifications. Ideally someone familiar with the cairo community would take this on, as Adrian found it hard to get the code approved upstream.

Skills: Understanding of basic color management, basic use of bzr and git, proficient in C.

Contact: Richard Hughes