Go back to the main GSoC Linux Foundation page

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

IRC: #openprinting on irc.linux-foundation.org

OpenPrinting developer resources

Code License: See project descriptions

Linux distributions try to support all available hardware out-of-the-box in their standard configuration, where this configuration is often limited to a single CD, so that the user can try out the distribution (and especially whether it supports his hardware) with a live CD before he installs it on his system.

With more and more hardware coming to the market and support for old hardware not being dropped in Linux distributions the distribution developers get into problems with the disk space.

Very space-consuming are the so-called PPD files (Postscript Printer Description files) for PostScript printers, mainly supplied by printer manufacturers. There is one PPD file for each supported PostScript printer, often for printers which are nearly the same (differ by only one extra paper tray, a duplex unit, password-protected printing added, …). The PPDs are rather big plain text files and the printing system (CUPS) only supports GZIP compression of each single file to save space. A standard Ubuntu installation has more than 60 MB oocupied with GZIP-compressed PPD files, a lot for a live CD, and these are not even all available PPDs.

Due to many printers having very similar capabilities the differences between many PPDs are little and by doing an appropriate grouping of the PPDs and saving for each group only one full PPD and the differences between this PPD and the other group members or one takes the PPDs apart into smaller units and saves identical units only once and references in the original PPD or … (whatever is your idea on a specialized compression algorithm for repositories of PPD files).

Your work will be developing and implementing an adapted data compression technique, you do not need knowledge about the printing workflow or about CUPS. You will not need to patch CUPS for this as CUPS allows pluggable modules to provide PPD files. So you write once a program which automatically compresses a directory structure full of PPDs (which will be called by the package build processes of the distributions) and a program which uncompresses the needed PPDs on demand (called by CUPS with a simple command line interface). Most challanging task will be finding the best compression algorithm and letting the best compression being done automatically.

Links: Simple code example for a PPD compressor, Ubuntu bug report with first discussion of the PPD problem, another, more recent Ubuntu bug report about this problem.

Mentor: Till Kamppeter, OpenPrinting Manager (till dot Kamppeter at gmail dot com)

Desired knowledge: C, compression and file comparison techniques, knowledge of the printing workflow is NOT needed.

Code License: GPL2 and later or other free software license

At the OSDL Printing Summit in Atlanta in April 2006 usability experts from OpenUsability were present and kicked off the design of a Common Printing Dialog for all desktops and applications under Linux. This dialog is once designed with usability in mind, studies about potential user groups and printer types were performed, paper prototyping and interaction design done, … and second, the overall usabilty of Linux will be improved by having the same printing dialog everywhere.

Now, near four years later, the design is completed and specifications for the dialog and its integration are available. Based on these specifications driver developers/printer manufacturers will be able to fit their drivers to the dialog and application and desktop programmers will be able to implement the common dialog.

During the Google Summer of Code 2008 and 2009 implementation of a Qt-based dialog has been completed and of a GTK-based dialog is close to completion. See the project page of the Common Printing Dialog.These implementations are supposed to be made part of the KDE and GNOME desktops and this way introduced into the Linux distributions. Applications should then call the dialog of the currently running desktop environment via a D-Bus API (CPDAPI). So if you run GNOME you see always the GTK incarnation of the dialog, even if you called it from a KDE application.

The student's task is to modify the standard GUI libraries GTK and Qt and also (if still needed after modifying the libraries) modify common desktop applications, like OpenOffice.org, Firefox, Thunderbird, the GIMP, digikam, … to use the CPDAPI. Also small changes on the dialogs themselves, for example in case of problems with the design of the CPDAPI, and completing the GTK dialog could be done by the student.

Lars Uebernickel, former GSoC student who implemented the D-Bus interface to couple the dialog with the applications (CPDAPI) and who also implemented a big part of the GTK GUI of the dialog, has already started to patch the GTK library, so this can be used as a start. Lars will also be the principal mentor for this project.

Our goal is to present ready-to-use patches for the integration of the Common Printing Dialog to the GNOME and KDE projects and also to application projects like OpenOffice.org, Mozilla, …

For this work we like to have one or two students doing it as a Google Summer of Code project. The students should be familiar with GUI programming, preferably with Qt and/or GTK. They also need the ability to dive into existing code and to modify and continue working on it, as here there is nothing new done from scratch. There is already code available. He/They has/ve to analyse the code of applications and GUI libraries and to see how they generate print jobs and open a printing dialog. He/They has/ve to do the modifications so that the applications talk bi-directionally with the dialog via D-Bus, being able to generate the live preview.

Mentors: Lars Uebernickel, developer of Foomatic 4.0, CDPAPI, implementations of the OpenUsability printing dialog (larsuebernickel at gmx dot de), Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till dot kamppeter at gmail dot com).

Desired knowledge: C/C++, GUI programming with Qt and/or GTK, modifying existing code

Code License: GPL/LGPL/Licenses of common desktop applications

Code Repositories: Common Printing Dialog D-Bus API (CPDAPI), Common Printing Dialog from OpenUsability

If you are on a modern Linux system and plug in a printer you usually get a print queue for it set up automatically, and if not, the printer setup tool selects the correct driver automatically for you when going through the printer setup wizard. For most printers and drivers the information which driver has to be used and how the driver is used with CUPS (Common Unix Printing System, standard printing environment for Linux and Mac) comes from a locally installed database, the Foomatic database. This is the same data as used by the OpenPrinting web site, but on local installations there is no SQL database but simply a bunch of XML files which provide the data.

These XML files (one per printer, one per driver, and one per user-settable driver option) are used to tell which printer works with which driver and also how the driver has to be called in the CUPS filter workflow. Unfortunately, with the steadily growing number of printers and drivers the processes of listing valid printer/driver combos and generating PPD files (Postscript Printer Description, files which tell CUPS about the capabilities of a printer and how to use the printer) is getting very slow. This makes it taking a significant time between discovery of a printer and getting a list of possible drivers.

The idea to improve the situation is introducing a local SQL database, to avoid an extra daemon SQLite should be used.

The database structure should be the same as on the OpenPrinting web site, as there are already written some methods for accessing the database. What has to be done is completing the databse access functionality in Foomatic's Perl library, adding methods to write data into the databse, remove data from the database, building an SQLite database from the XML data, importing XML data from packages and removing it, optimizing speed, testing everything and making it ready for a new release of Foomatic.

With the success of this project printer setup in all Linux distributions will get much faster. Ideally the make/model/driver list will show up instantly.

Mentor: Till Kamppeter, OpenPrinting Manager (till dot Kamppeter at gmail dot com)

Desired knowledge: Perl, SQL

Code License: GPL2 and later

Code repositories: Foomatic

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:

• make it possible to print from linux applications through cups or other spoolers with more(all?) WIN32 drivers

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

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. These job tickets do not only make sense for large-scale production printing, they are also useful for mobile devices, home desktops, workgroup printers, … Also access to print services on the internet directly from the desktop applications simply via a print queue would be possible.

To allow desktop applications, printing systems, and printer drivers to easily create, edit, and read job tickets without needing to deal with the actual job ticket format, the job ticket application programming interface (JTAPI) was developed by OpenPrinting. A complete specification is published.

The next step to do is the actual implementation of the JTAPI library and its integration in applications, the CUPS printing system, drivers, filters, … This will be the task of the student in this Google Summer of Code project.

Proposed Tasking:

Objective: Using the header files created by the Open-Printing Job-Ticket Working Group develop a platform independent C library for the reading-of, modification-of and storage-of a print job ticket for the Printer Working Group’s (PWG’s) Micro-Job-Ticket (MJT).

Approach:

1. Review OP/JTWG Job-Ticket Application Programming Interface (JTAPI)header documents
2. Review PWG/MJT specification.
3. Create Test MJT’s
   1. Manually create a minimum of 3 representative MJTs (text files) to be used for testing and evaluation
4. Define the command-line Test Application to exercise the JTAPIs; include an initial set of commands
5. Create Thin-Thread implementation of the individual JTAPIs and the Test Application.
   1. This will be the first demonstrational implementation and the start code for detailed development.
   2. This will include minimum documentation on how to use the Test Application
6. Enhance individual JTAPIs and the Test Application to provide full functionality.
   1. Provided update documentation as required.
7. Project Demonstration.

Code License: CPL

Coding Language: Platform Independent C (No platform or vendor-specific extensions)

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

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

Interface: Command Line – GUI not required unless very simple (due to project time constraint)

Document: Minimum:

1. How to build the JTAPI library.
2. How to build the Test Application
3. The Test Application command-line instructions
4. Three examples of using the Test Application and exercising the JTAPIs

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

Desired knowledge: C Programming

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. These job tickets do not only make sense for large-scale production printing, they are also useful for mobile devices, home desktops, workgroup printers, … Also access to print services on the internet directly from the desktop applications simply via a print queue would be possible.

To allow desktop applications, printing systems, and printer drivers to easily create, edit, and read job tickets without needing to deal with the actual job ticket format, the job ticket application programming interface (JTAPI) was developed by OpenPrinting. A complete specification is published.

This is a parallel project to actual implementation of the JTAPI library by providing a JDF Job-Ticket Front-End. This will be the task of the student in this Google Summer of Code project.

Proposed Tasking:

Objective: Using the header files created by the Open-Printing Job-Ticket Working Group develop a platform independent C module for accepting, parsing, interpreting and translating JDF Job-Tickets to JTAPI objects/attributes using the JTAPI's.

Approach:

1. To Be Determined

Code License: CPL

Coding Language: Platform Independent C (No platform or vendor-specific extensions)

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

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

Interface: Command Line – GUI not required unless very simple (due to project time constraint)

Document: Minimum:

1. How to build the JDF Job-Ticket Module.
2. How to build the Test Application
3. The Test Application command-line instructions
4. Three examples of using the Test Application and exercising the JTAPIs

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

Desired knowledge: C Programming