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
Code License: GPL
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
Code License: GPL
In the free software world there are often several different projects for fulfilling the same task. For rendering (rasterizing) PDF (the standard format for print jobs) there are Poppler and Ghostscript. Both have there advantages and disadvantages, for example Poppler is completely written in C++ whereas the PDF interpreter of Ghostscript is written in PostScript (note that PostScript is a full-featured programming language), which makes Poppler smaller and faster. Ghostscript's advantage is having better color management and being better optimized for printing.
Unfortunately, one cannot freely choose between the two yet as Ghostscript has many important printer driver, especially “pxlcolor”/“pxlmono”, built in and so dropping Ghostscript in favor of Poppler would lead to a loss of important functionality, like PCL-XL printer support.
To avoid this we need to make all printer drivers working with arbitrary renderers. 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 suggested 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 as 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.
Mentor: Hin-Tak Leung (HinTak dot Leung at gmail dot com), author of several drivers for printers with proprietary protocols; Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till at linux dot com)
Desired knowledge: Knowledge in C programming is required. Great is also knowledge in PostScript and the Linux/Unix printing workflow.
Code License: GPL
There was a Google Summer of Code 2007 project under wine [1] to use WIN32 drivers to print from wine, and some adaption of that idea in some limited fashion in ddiwrapper [2]. It would be quite interesting and useful to properly integrate this into the more general printing workflow:
Currently there are two(?) frameworks which are usable for loading binary-only closed-source vendor driver modules, OPVP and IJS. There are a few other FOSS projects which uses some part of wine to load binary-only WIN32 modules for accessing data in proprietary format quite successfully - e.g. ndiswrapper (for wireless network hardware), mplayer (for multimedia playback).
Some background information is in [3]
Mentor: Hin-Tak Leung (HinTak dot Leung at gmail dot com), author of several drivers for printers with proprietary protocols; Detlef Riekenberg from the Wine Project, who was the mentor for the Gsoc 2007 wine project for print proxy, has agreed to be involved.
Desired knowledge: C programming
Code License: GPL/LGPL/Public Domain
Since four years the OpenPrinting web site uses a PHP/MySQL based web application to administer a growing printer and printer driver database. Currently the site supports searching and listing of printers and drivers, download and submission of PPD (Postscript Printer Description) and drivers and a rudimentary backend interface for moderation of submissions.
While all basic functionality is given, there are a lot of areas to improve. The long forms related to driver and printer submission could be shortend and moved to an assistant that allows for an easier and faster submission process. The moderation process could be simplified to allow an even faster overview for moderators and administrators. There are a lot of small issues where usability could be enhanced, for example links to create a similar printer, duplicating an existing record.
The backend processing is another part that should be improved. Currently all scripts and build routines of the project are mostly tight to server environment that serves the web site. Beside building more generalized scripts, the student could also automate the import and update process of Printer Description files in the exisiting BZR repository.
Basic email notifications for administrators and moderators exist, but optional notifications for uploaders are still missing.
There is still a lot of manual work involved, that could be simplified or automated to leave more time to contributors and administrators to work in drivers and printer descriptions itself.
Mentors: Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till at linux dot com), Jeff Licquia, The Linux Foundation (jeff at licquia dot org)
Desired knowledge: PHP, MySQL, web interface programming, (Bash) scripting, basic usability experience Code
License: GPL
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