To make printing easy for the users of desktop systems and mobile devices he once needs a well-designed print dialog where he can easily find the right printer under the available printers, set general, printer-specific, and document-specific options, preview the printout, and send the job. But he also neds consistence between applications, printing should work the same way from every application, the print dialog should be the same all over the system.
For the dialog itself there is already a design of how the user interface could look like. It was done by the design team of Canonical (the company behind Ubuntu) and can be found on the Ubuntu Wiki. The dialog should support twoways of obtaining available printers: Most importantly it should list the local CUPS queues and get printer properties and options through CUPS. I also should be able to pick IPP network printers from the network via Bonjour/DNS-SD and query the printer's properties via IPP (mainly for mobile devices to use IPP Everywhere and AirPrint printers).
To allow for the print dialog being provided by the currently running desktop (Unity, GNOME, KDE, …) or mobile environment while the different applications use different GUI toolkits (GTK, Qt, …) the print dialog and the application should be implemented in different executables which communicate by D-Bus. An appropriate D-Bus interface got already designed earlier. Probably the designe can already be used as it is, perhaps it needs some slight modifications.
The task for the student(s) is to implement the dialog with a major toolkit (GTK or Qt) or to add the D-Bus interface to call the Common Print Dialog to a major toolkit or an aimportant application.
At OpenPrinting there has already been worked on a similar project earlier. See the resources here.
This project will be divided under several students (GTK dialog, Qt dialog, D-Bus interfaces for applications/GUI toolkits, …).
Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Ubuntu GUI developers TBD
Desired knowledge: C/Cprogramming, GUI programming, GTK, Qt, D-Bus
=====Flattening non-static content (like filled forms) in PDF files for printing (1 student)=====
Mentors: Tobias Hoffmann (smilingthax at googlemail dot com), Jay Berkenbilt (ejb at ql dot org) TBD
Desired knowledge: C/C++ programming
=====Improve the pdftopvp filter to not need copying Poppler source code or unstable APIs and/or make it Ghostscript/MuPDF-based (up to 3 students)=====
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, Project Leader OpenPrinting (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: Improving the PPD generation capabilities: Option conflicts and printer compatibility classes (1 student)=====
[[:openprinting:database:foomatic Foomatic]] serves now well for more than 15 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), to the OpenPrinting web site, and to the PPD file generator.
Mentor: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com)
Desired knowledge: Perl programming, PHP, MySQL
Code License: GPL
=====Foomatic: Generating CUPS PPD generator (/usr/share/cups/drv/*.drv files) from Foomatic data (1 student)=====
CUPS has two mechanisms for on-the-fly-PPD generation to avoid the wasting of disk space by thousands of 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, Project Leader OpenPrinting (till at linux dot com)
Desired knowledge: Perl programming, perhaps also MySQL
Code License: GPL
=====Get the cairo color management code upstream (1 student)=====
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 (hughsient at gmail dot com)
=====Add printer output backends to MuPDF (1-2 students)=====
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, Project Leader OpenPrinting (till at linux dot com)
Desired knowledge: C and/or C programming
Code License: GPL
