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
IPP, the Internet Printing Protocol from the Printing Working Group (PWG) is a standard protocol for network printers (and also used by CUPS, the standard printing environment on practically all non-Windows operating systems). IPP network printers have a lot of advantages compared to USB printers (letting the ability of several computers on a network being able to access them aside):
All this works with standard protocols and without any requirement of printer manufacturer/model specific software. For printers which also understand standard languages for the jobs themselves (PostScript, PDF, PWG Raster, PCL, JPG, TIFF) this means completely driverless printing (IPP Everywhere).
Unfortunately, this is a network protocol for network printers.
Fortunately, the USB Implementers Forum has added a standard to make it also go into USB printers, IPP-over-USB. Problem is that there is no Linux support for that.
This project is about creating the appropriate support on Linux systems with a CUPS printing environment. What has to be done is writing a daemon which is started and stopped via UDEV when an appropriate printer (with USB protocol 4) is connected and disconnected. The running daemon should make available an IPP interface and the web configuration interface to the system on TCP ports (getting URIs like ipp:localhost:4000/ and http://localhost:4001/) and it also should register the URIs at avahi-daemon so that Bonjour-based auto discovery of the printer is possible (for example by cups-browsed). A plus is to use systemd and Upstart to run this daemon on-demand, socket-triggered. The student's task is to study the protocol specification and to implement it in a simple UDEV-triggerable daemon, opening two ports on localhost to access the printer and to register the URIs at avahi-daemon. There are enough code examples around in existing printing-related free software projects to put this together (Avahi library use in cupsd and cups-browsed, libusb use in the “usb” CUPS backend, UDEV use in system-config-printer, …) We will make arrangements for the student to get a sample printer for testing. Mentors: James Cloos (cloos at jhcloos dot com), Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till at linux dot com). Desired knowledge: C programming Code License: MIT or GPL =====Complete IPP Everwhere support of CUPS: rastertopdf filter to accept PWG Raster as input format===== CUPS, the standard printing system of Linux, Unix, and Mac OS X, was always following the standards of the Printing Working Group (PWG), especially the Intrnet Printing Protocol, IPP. Michael Sweet, author of CUPS, is actively participating in the PWG work. Recently the PWG has completed the new IPP Everywhere standard for printers, which allows driver-less (no printer-model-specific software on the client) printing by using IPP and standard printer languages, like PostScript, PDF, and PWG Raster, the latter being required for all IPP Everywhere printers. To not only get easy network printing with the new IPP Everywhere printers but also with any printer shared by a CUPS server on a Linux/Unix system we want CUPS being able to fully emulate an IPP Everywhere printer. cups nearly does it, it does the newest IPP and accepts PostScript, PDF, and JPEG as input, but it does not accept the required PWG Raster. The student's task in this project will be writing a rastertopdf filter for the cups-filters upstream project of OpenPrinting (official filter suite for CUPS 1.6.x or newer) which turns PWG Raster into PDF and so allows CUPS to take PDF as input. Preferably he makes use of the imagetopdf filter for that making it supporting multi-page input (with the side effect of multi-page TIFF support) and adding PWG Raster to this filter. Mentors: Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till at linux dot com), Tobias Hoffmann (smilingthax at googlemail dot com) TBD Desired knowledge: C and/or Cprogramming Code License: MIT, GPL =====GTK (GNOME) Print Dialog: Support for driver-less printing on network printers, especially also IPP Everywhere printers===== cups-browsed is a daemon which comes with the [[:openprinting:cups-filters programming Code License: MIT, GPL =====Add printer output backends to MuPDF===== MuPDF is a lightweight PDF renderer made by Artifex, the company behind Ghostscript. In contrary to Ghostscript, MuPDF is a pure PDF renderer. It does not contain a PostScript interpreter nor parts of it are written in PostScript. This makes it smaller, faster, and less resource-consuming, the ideal solution for mobile devices like tablets or smartphones. On mobile devices printing will not be done with having tons of printer-model-specific drivers on the system. Once, they consume the limited mass storage space, and second, one uses the mobile device in several different local networks with different printers: At home, in the office, in a copy shop, … and one wants to use the printers which are available there, without installing drivers and setting up queues. Therefore we want to have a system which automatically detects network printers and makes them available for local apps. To do so we restrict ourselves to printers with known, common languages: IPP Everywhere (Upcoming standard, PWG Raster and optionally some others) and PostScript, PDF, PCL 5c/e/6/XL (legacy standards). So MuPDF has to generate raster output for these languages, meaning raster embedded in the specifics of the language, and to avoid exhausting printer resources raster in small bands and no high-level output, even if the printer language is high-level. Artifex will also work on this, but to get additional man power we are also opening this project for students. Note that you have to assign copyright on your code to Artifex, as otherwise the code cannot be integrated in MuPDF. This project can be split to be worked on by more than one student. Mentors: MuPDF developers TBD, Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till at linux dot com) Desired knowledge: C and/or Cprogramming Code License: GPL =====Improve the pdftopvp filter to not need copying Poppler source code or unstable APIs===== The cups-filters project at OpenPrinting (included in all Linux distributions using CUPS 1.6.x or newer) provides the filters needed to convert the print job output of desktop applications (usually PDF) into the printer's native language or into the universal CUPS/PWG-Raster format as input for a separate printer driver. It also provides the pdftopdf filter to apply page management (N pages per sheet, selected pages, even/odd pages for manual duplex, mirror for iron-on sheets, ...) to the PDF data stream. One of the filters is pdftoopvp which is the interface between PDF (the standard print job format under Linux) and the OpenPrinting Vector high-level printer driver interface standard. This standard is currently used by several Japanese-market laser printers which do not use PostScript as it is usual in Europe and the US. This filter currently only supports Poppler as PDF renderer and the connection between the filter and Poppler is rather awkward, copying parts of Poppler's source code and using unstable APIs of Poppler which change with newer Poppler versions. This makes maintaining the filter difficult for the Linux distributions. The task for the student is here to once improve the interface with Poppler if possible and also add support for Ghostscript (would improve color management a lot) and MuPDF (would improve integration with mobile and embedded devices). Mentors: Till Kamppeter, OpenPrinting Manager, The Linux Foundation (till at linux dot com), Koji Otani, BBR Inc. Japan (sho at bbr dot jp) Desired knowledge: C and/or C++ programming Code License: MIT =====PWG Job-Ticket backend for libJTAPI (Job Ticket API)===== 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. IPP Everywhere is a next generation printing protocol by the Printing Work Group (PWG) and uses job tickets for all printing metadata. This makes job ticket handling vital for IPP Everywhere support. For IPP Everywhere the PWG has created the [[ftp://ftp.pwg.org/pub/pwg/candidates/cs-sm20-pjt10-20120801-5108.07.pdf 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 =====Vendor WIN32 driver made available to Linux applications===== 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 =====Get the cairo color management code upstream===== Adrian Johnson did a lot of the work needed to make cairo color managed. Finishing this work and getting the code upstream would allow us to simplify a lot of applications that use cairo. See http://cgit.freedesktop.org/~ajohnson/cairo/log/?h=color-space for the branch. Adrian has also patched Inkscape to use the new features, and that needs cleaning up and pushing upstream http://cgit.freedesktop.org/~ajohnson/inkscape/log/?h=color-space Also see http://lists.cairographics.org/archives/cairo/2012-July/023353.html and https://mail.gnome.org/archives/gimp-developer-list/2012-August/msg00084.html for more details. Expectations: The cairo and inskcape code is pushed upstream with any required modifications. Ideally someone familiar with the cairo community would take this on, as Adrian found it hard to get the code approved upstream. Skills: Understanding of basic color management, basic use of bzr and git, proficient in C. Contact: Richard Hughes