For getting a great user experience with printing there is still a lot of coding needed. See our projects described below. Your contribution is highly appreciated. As we want our work to get a standard, we will let every completed project get into the major Linux distributions, so your work will help a lot of Linux users and will make Linux a better OS.

Enter the amazing world of free software and help fixing bug #1 of Linux.

We are also searching for sponsors, who either fund the work on the projects or let their employees work on them.

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

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

OpenPrinting developer resources

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 and a GTK-based dialog has been nearly completed. 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 task we need to be worked on 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 completing the dialogs themselves and small changes on them, for example in case of problems with the design of the CPDAPI, needs to be done.

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 technical contact 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, …

Contacts: Lars Uebernickel, developer of Foomatic 4.0, CDPAPI, implementations of the OpenUsability printing dialog (lars at uebernic dot de), Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till at linux dot com).

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

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

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 three frameworks which are usable for loading binary-only closed-source vendor driver modules, OPVP, IJS, and CUPS Raster. 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]

Probably easier would be to write a wrapper for Mac OS X drivers, as these are already CUPS drivers which typically accept CUPS Raster or PDF input and use PPXD files, but there are usually more printers supported under Windows than under Mac. Nevertheless a wrapper to use Mac OS X drivers under Linux would already be a great step forward.

Contact: 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.

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 for this 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 required the Printer Working Group’s (PWG’s) Print-Job-Ticket (PJT).

Approach:

1. Review OP/JTWG Job-Ticket Application Programming Interface (JTAPI)header documents
2. Review PWG/PJT specification.
3. Create Test PJT’s
   1. Manually create a minimum of 3 representative PJTs (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.

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

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

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 PWG:Print-Job-Ticket Front-End.

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 PWG:Print-Job-Tickets to JTAPI objects/attributes using the JTAPI's.

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.

Document: Minimum:

1. How to build the PWG:Print-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

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