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 irc.linux-foundation.org

OpenPrinting developer resources

Code License: See project descriptions

The application period has started! Please go to the GSoC site and click the link for student applications, the choose “The Linux Foundation” as mentoring organization. Deadline is Friday, April 8, 2011. Do not forget to read and follow the DOs and DON'Ts for students and our student application template.

Note: Color Management is currently on the way into the distributions and it is a great step to improve the printing experience. See the color-management-related projects on the ideas page of OpenICC.

Two years ago, we have replaced the web app of the OpenPrinting web site by a PHP/MySQL-based system. Acceesing the site for reading the entries and downloading PPD (Postscript Printer Description) files and printer drivers works very well and the overload problems of the old site are gone.

A feature which was in our plans but got never completed is the possibility for users to enter and edit entries and for mederators to approve or reject these changes, all by an easy-to-use web interface. There is some start, like working input (not edit/moderation) forms for new printers and drivers and also overview tables for the new entries.

The student's task in this project will be extend the input forms so that the original poster and also moderators can edit the entered data set and moderators can also approve, reject, delete it, and also be able to merge entries from different users for the same printer/driver. In case of approval the entry should get marked as such, so that the automatic syncing lets it go into the Foomatic packages (printer database used by the Linux distributions). On all printer and driver pages should be “Edit” and “Add similar” links. Also e-mail notification for smooth communication between posters and moderators should be set up.

All in all, it should be easy to contribute printer and driver entries and later correct them and for moderators it should be easy to quickly sort out the good and bad ones and correct and merge them if needed, and also ask posters for more info.

Mentors: Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till at linux dot com), David Ames (david at linuxfoundation dot org)

Desired knowledge: PHP, MySQL, web interface programming, modifying existing code

Code License: GPL

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 five years later, the design is nearly 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 and make use of the common dialog.

During the Google Summer of Code 2008 and 2009 implementation of a Qt-based dialog has been worked on and of a GTK-based dialog is also 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 D-Bus API was already designed in a former Google Summer of Code and the patching of applications and GUI toolkits should be done by other students during this Google Summer of Code (see below). What still needs to be done is to complete the coding of the dialogs to meet the specs and to make them ready to be submitted to the KDE and GNOME projects as patches.

For these coding tasks we like to have two students doing them as a Google Summer of Code project. The students should be familiar with GUI programming, preferably one with Qt and the other with 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. The dialogs must be adjusted to fulfill size and appearance requirements, feature completeness has to be assured (CUPS filter options, support for internationalized PPDs, support of all PPD extensions, …), error handling, and integration in the desktop code bases.

And the most important: The students have to work in a team with the students of the project of modifying the toolkits and applications (see below).

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

Desired knowledge: C/C, GUI programming with Qt and/or GTK, modifying existing code Code License: GPL/LGPL Code Repositories: [[http://bzr.openprinting.org/misc/cpdapi Common Printing Dialog D-Bus API (CPDAPI)]], Common Printing Dialog from OpenUsability =====Modifying Desktop Applications so that they use a Common Printing Dialog ===== 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. An important part of the architecture is that the printing dialog is not supplied by a GUI toolkit library (GTK or Qt) linked with the application, but the application calls a printing dialog supplied by the desktop environment via D-Bus. This way all applications will use the same printing dialog. The Common Printing Dialog itself is not completed yet, but the D-Bus interface (CPDAPI) is already designed and first attempts to get it into GTK were already done. In this project we want to modify GTK, Qt, and also some applications (like LibreOffice) to call the printing dialog via D-Bus and so we can make the GTK printing dialog appear for all applications if the user uses GNOME and the Qt dialog if the user uses KDE. This is already a great first step, and it is no big deal to later replace the printing dialog by OpenUsability's dialog. 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 LibreOffice, Firefox, Thunderbird, the GIMP, digikam, … to use the CPDAPI. Also small changes on the desktop's printing dialogs, for example in case of problems with the design of the CPDAPI 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 Common Printing 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 D-Bus interface to the GNOME and KDE projects and also to application projects like LibreOffice, 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. Mentors: Lars Uebernickel, developer of Foomatic 4.0, CDPAPI, implementations of the OpenUsability printing dialog (lars at uebernic dot de), Hal V. Engel, KDE developer (hvengel at gmail dot com), Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till at linux 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

This project is a cooperation of OpenPrinting and OpenICC it is also offered in the project ideas list of OpenICC.

Artists and Pro Users want to configure custom ICC profiles. This should be simple and easy. The Common Printing Dialog (CPD) is the ideal place to let users interact in an intuitive way. colord (GNOME/GTK) and Oyranos (KDE/Qt) will ensure a very robust configuration of ICC device profiles. OpenUsability, OpenPrinting and OpenICC outlined a concept on how to best integrate colour management into CPD.

Expectations

• Add profile selector to the CPD
• Use Oyranos/colord device APIs to assign an ICC profile
• Add few user visible options
• Use the Poppler/Ghostscript renderers for ICC profile in PDF
• Add robust checking for correct functionality
• Careful coding and comments
• End user documentation

Skills

• Rather simple programming task
• Good communication
• C++, C, shell
• git

Mentor

Kai-Uwe Behrmann, color management expert and author of Oyranos (ku dot b at gmx dot de). Co-mentors could be Richard Hughes, color management expert of Red Hat and author of colord (hughsient at gmail dot com) and Lars Uebernickel, developer of Foomatic 4.0, CDPAPI, implementations of the OpenUsability printing dialog (lars at uebernic dot de).

Code License

GPL/LGPL

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

All print jobs, large and small, require two components; namely, a job ticket and print content. Both of these take on many forms; for example, print content ranges from PDF to JPEG to TEXT to MS-WORD to LIBRE-WRITER to POWER POINT and countless others. All modern print solutions today either directly or indirectly (via the source application and/or transforms) support the various types of print content. Like print content, (print) job tickets come in numerous formats and even large ranges of content and capabilities. As OpenPrinting moves to provide coherence for printing and as printing moves to the Cloud where the source of the a print job is no longer the platform the user is working on, there needs to be a common solution for not only editing (print) job tickets but to also transform (print) job-tickets from one format to another while the print job moves through a Linux print solution (transforms, spoolers and print-managers) or through a federation of Clouds. A previous OpenPrinting activity created a specification and C code binding for a set of Application Programming Interfaces (APIs) called “JTAPI” to provide the necessary edit and transform functions. The JTAPI specification shows that it can be used to support mobile (cloud) devices, desktop, office and production printing solutions; demonstrating the eventual use for any print solution or printing need. “Behind” the JTAPI implementation are anywhere from one to many(-many-many) specific job-ticket format bindings (such as JDF, PWG Job-Ticket, etc) that will be added to this base implementation as a separate GSOC project.

This year, the OpenPrinting GSOC project would like to create the core or base set of C code for a JTAPI implementation. The complete specification for JTAPI is available.

Proposed Tasking:

Objective

Using the existing JTAPI specification and C code header files the objective of this project is to develop, document, test, and release a platform-independent C code library for the reading of, modification of, and storage of a (print) job-ticket. Since creation of the base library will actually needs a (print) job-ticket for development; the Printer Working Group's (PWG's) Micro-Job-Ticket (MJT) can be used as an illustrative job ticket for the purpose of developing the core implementation.

Approach:

1. Review OP/JTWG Job-Ticket Application Programming Interface (JTAPI) header document
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, should work on as many platforms as possible)

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 – 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, should work on as many platforms as possible)

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 – 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

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.

In addition the XML handler needs to be improved in terms of maintainability. Ten years ago, when there wer no good Perl solutions to handle XML, two rather awkward C programs got inserted into the Perl library to accelerate the parsing of the XML files. These programs should be replaced by one program or even by pure Perl code to make maintenance and addition of feature much easier. This will especially help to implement support for option conflicts (“*UIConstraints:” in PPD files) and printer compatibility classes.

The student will not only code up the changes on Foomatic but also do research work on getting the best performance.

With the success of this project printer setup in all Linux distributions will get much faster and further development of Foomatic will get easier.

The results of this project will get core features of the Foomatic 4.1.x or 5.0.x series.

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

Desired knowledge: Perl, SQL

Code License: GPL2 and later

Code repositories: Foomatic