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 Freenode

OpenPrinting developer resources

Code License: See project descriptions

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.

We have completed to replace PostScript as standard print job format by PDF: Applications send print jobs in PDF format and CUPS (the printing system used by Linux) converts all incoming data to PDF, does the page management (N pages per sheet, reverse order, selected pages, scaling, …), and sends the PDF data stream off to the print renderer (usually Ghostscript).

The page management is currently done by a filter based on Poppler. Poppler is not intended for manipulating PDF files but only for displaying them on the screen or converting them to raster image formats. Therefore it required awkward hacks to write this filter with Poppler, especially some of Poppler's source code needed to be copied into the filter's source code and slightly modified there. If these code pieces have bugs, especially security vulnerabilities, not only Poppler needs to get updated but also the filter and this is easily overlooked, leaving security vulnerabilities in the filter. In addition, Poppler's APIs are not very stable which needs frequent adaptations of the filter.

One can think about pdftk, but pdftk is written in Java and as Java is a large and resource-consuming software package, pdftk is not suitable to be used as a piece of system software, especially having lice CDs and embedded systems in mind.

Our filter does not need to interpret PDF nor does it need to create complex graphical structures in PDF. It only has to re-arrange PDF files to change the page order, drop unwished pages, scale pages, and the PDF format is separating the data for the pages well so that manipulating the pages without needing to interpret the code should be possible (keep in mind that this was one of the reasons why we switched to PDF as print job format).

The project is to write a lightweight C or Cprogram avoiding the use of libraries with unstable APIs or high demands on resources which does all types of manipulations on PDF files which the pstops filter of current CUPS does on PostScript files. These are * Page scaling, especially to fit a requested page size and margins * Positioning the page content * Mirroring pages horizontally and vertically * Rotating pages by 90, 180, and 270 degrees * Draw a rectangle around the page content * N-up: N pages per sheet in different orders * Only keep selected pages * Only keep even or odd pages * Reverse the order of the pages * Generate multiple copies of the pages, optionally collated This should be implemented with two frontends, a pdftopdf CUPS filter and an easy-to-use command-line tool. If this work gets completed before the end of the coding period, as a smaller additional project the currently Poppler-based pdftoopvp filter (PDF to OpenPrinting Vector) which also copies Poppler source code couls be replaced by a compatible Ghostscript-based one. The resulting code will get into our [[:openprinting:pdf_as_standard_print_job_format OpenPrinting's cups-filters package]]. Later on (not part of the Google Summer of Code) this project could be continued adding more manipulation functions, like booklet printing for example. Mentors: Lars Uebernickel, printing software developer (lars at uebernic dot de), Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till at linux dot com) Desired knowledge: C and/or C programming

Code License: GPL

Three 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), Jeff Licquia, The Linux Foundation (jeff at licquia dot org)

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

Code License: GPL

foomatic-rip is a universal print filter to work as a wrapper around Ghostscript to make the use of Ghostscript-based printer drivers with arbitrary printing systems simple. In the times back when the Foomatic project started there were many printing systems available for Linux: LPD, GNUlpr, LPRng, CUPS, PDQ, PPR, CPS, … and they were all supported by Foomatic. Currently practically only CUPS is used and CUPS is also the only printing system with ongoing development and solid maintenance. The other systems are not maintained and developed any more (only very little activity on LPRng) and only rarely used.

The idea is to make a replacement for the foomatic-rip filter which supports only CUPS and drops all the code for the other printing systems which gets only rarely used and therefore very difficult to maintain and test. The remaining code should also simplified as much as possible to get best maintainability.

Mentors: Lars Uebernickel, printing software developer (lars at uebernic dot de), Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till at linux dot com)

Desired knowledge: C and/or Cprogramming Code License: GPL =====Foomatic: Improving the PPD generation capabilities: Option conflicts and printer compatibility classes===== [[:openprinting:database:foomatic 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 =====Modularization of built-in GhostScript drivers into an OPVP driver===== 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:

• 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