======Google Summer of Code 2012: OpenPrinting projects======

[[:gsoc:google-summer-code-2012|Main GSoC Linux Foundation page: How to apply, deadlines, other workgroups, ...]]
=====Contact=====

**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: [[http://lists.linux-foundation.org/mailman/listinfo/printing-architecture|printing-architecture at lists dot linux-foundation dot org]]

IRC: #openprinting on Freenode

[[:openprinting:development|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 [[http://www.freedesktop.org/wiki/OpenIcc/GoogleSoC2012|OpenICC]].**

 
=====Lightweight tool for manipulation of PDF files for printing: N pages per sheet, reverse order, selected pages, scaling, ...=====

We have completed to [[:openprinting:pdf_as_standard_print_job_format|replace PostScript as standard print job format by PDF]]: Applications send print jobs in PDF format and [[http://www.cups.org|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 [[http://www.ghostscript.com|Ghostscript]]).

The page management is currently done by a filter based on [[http://poppler.freedesktop.org/|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 [[http://www.pdflabs.com/tools/pdftk-the-pdf-toolkit/|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 C++ program 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\\ 
=====OpenPrinting web site: Creating a web app for entering, editing, and approving new printer and driver entries=====

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: Replace the universal print filter by an easy-to-maintain CUPS filter=====

[[:openprinting:database:foomatic|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, [[http://sourceforge.net/projects/lpr/|GNUlpr]], [[http://lprng.sourceforge.net|LPRng]], [[http://www.cups.org|CUPS]], [[http://pdq.sourceforge.net|PDQ]], [[http://ppr.sourceforge.net|PPR]], [[http://freecode.com/projects/cps|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 C++ programming

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 [[http://poppler.freedesktop.org|Poppler]] and [[http://www.ghostscript.com|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 "[[http://www.openprinting.org/driver/pxlcolor/|pxlcolor]]"/"[[http://www.openprinting.org/driver/pxlmono/|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
=====Vendor WIN32 driver made available to Linux applications=====

There was a Google Summer of Code 2007 project under wine [[http://code.google.com/p/google-summer-of-code-2007-wine/downloads/list|[1]]] to use WIN32 drivers  to print from wine, and some adaption of that idea in some limited fashion in ddiwrapper[[http://www.novell.com/products/linuxpackages/opensuse/ddiwrapper.html|[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 [[https://www.linuxfoundation.org/en/User:Htl10|[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 Ticket API (JTAPI) implementation=====

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 [[ftp://ftp.pwg.org/pub/pwg/fsg/jobticket/JTAPI_Spec/fsg-openprinting-job-ticket-api-v0100-20050315.pdf|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 [[ftp://ftp.pwg.org/pub/pwg/fsg/jobticket/JTAPI_Spec/fsg-openprinting-job-ticket-api-v0100-20050315.pdf|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:**//

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

  - How to build the JTAPI library
  - How to build the Test Application
  - The Test Application command-line instructions
  - 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
=====JTAPI (Job Ticket API) JDF Job-Ticket Implementation=====

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 [[http://en.wikipedia.org/wiki/Job_Definition_Format|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 ([[https://www.linuxfoundation.org/en/OpenPrinting/JTAPI|JTAPI]]) was developed by OpenPrinting. A complete [[ftp://ftp.pwg.org/pub/pwg/fsg/jobticket/JTAPI_Spec/fsg-openprinting-job-ticket-api-v0100-20050315.pdf|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:**//

  - 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://

  - How to build the JDF Job-Ticket Module.
  - How to build the Test Application
  - The Test Application command-line instructions
  - 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