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

The participation of the Linux Foundation in the Google Summer of Code is organized by Till Kamppeter (till at linux dot com) and Aveek Basu (basu dot aveek at gmail dot com).

In the classic user interfaces you select at first a printer for printing a job and then you adjust the settings on these printer to the needs of the job. So you usually see a more or less long list of printers and do not really know which one is the best for the job you want to print. You select one, see the options and then you go back and select another one.

What about not having to select a printer at all and simply see options, like paper size, paper type, job type (text, photo, drawing, …), color/grayscale, print quality, double-sided, booklet maker, … and depending on how you set the options the system will automatically select the best printer for you and give you a notification to which printer your job gets sent. So no knowledge about available printers and their capabilities is needed.

To do so we want to cluster an arbitrary collection of printers (all available printers, all of one office floor, …) into one queue with a merged PPD file (all options of all printers available, option conflicts if selection cannot be obeyed on one single printer). The user selects options (and document type, like text, photo, … is also submitted) and the printer (or printers) to print the job on get auto-selected by cups-browsed. The user does not need to know which printers are available and what they are capable of.

An interesting idea for a new concept of printing user experience.

Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD

Desired knowledge: C programming, CUPS

Code license: LGPL 2.1+

Version 2.0 and newer of the Internet Printing Protocol (IPP) support polling the full set of capabilities of a printer and if the printer supports a known Page Description Language (PDL), like PWG Raster, Apple Raster, PCLm, or PDF, it is possible to print without printer-model-specific software (driver) or data (PPD file), so-called “driverless” printing. This concept was introduced for printing from smartphones and IoT devices which do not hold a large collection of printer drivers. Driverless printing is already fully supported under Linux. Standards following this scheme are IPP Everwhere, Apple AirPrint, Mopria, and Wi-Fi Direct Print.

As there are many multi-function devices (printer/scanner/copier all-in-one) which use the IPP, the Printing Working Group (PWG) has also worked out a standard for IPP-based scanning, “driverless” scanning, to also allow scanning from a wide range of client devices, independent of which operating systems they are running.

Conventional scanners are supported under Linux via the SANE (Scanner Access Now Easy) system and require drivers specific to the different scanner models. Most of them are written based on reverse-engineering due to lack of support by the scanner manufacturers. To get driverless scanning working with the software the users are used to the best solution is to write a SANE module for driverless IPP scanning. This module will then automatically support all IPP scanners, thousands of scanners where many of them do not yet exist.

The student's task is to write this SANE module for IPP driverless scanning and so make Linux ready for the future of driverless devices.

Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), SANE upstream developers TBD

Desired knowledge: C programming, DNS-SD, IPP

Code license: GPL 2+

The Internet Printing Protocol (IPP) does not only support printing, but also scanning, as there are many printers which also have a scanner (multi-function (MF) devices). Both CUPS and the developer tool ippserver emulate IPP network printers but not IPP scanners and so they cannot serve as a server to share a local scanner.

This task is about adding the scan server functionality. If you have a scanner connected locally (and it scans via SANE), share it via CUPS as an IPP scanner, advertising itself and accepting jobs using the IPP driverless scanning standard. In contrary to SANE-based network scanning clients with any operating system, also phones or IoT devices can scan on your shared scanner.

Also old hardware can be recycled to a modern MF device, and we have a sample implementation to motivate manufacturers to adopt IPP scanning.

Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD

Desired knowledge: C programming, DNS-SD, IPP

Code License: Apache 2.0

Most network printers have a web interface which allows to configure the printer from any computer in the network using a web browser. Advantage is that no printer-model-specific software needs to be installed on the computer in order to configure a printer, and one has no dependency on certain supported operating systems. One can even configure printers using a smartphone.

Disadvantage is that every manufacturer does its web interface differently which makes administration of many printers of different brands awkward. In addition, automated printer administration with scripts requires different interfaces for each printer. And for setting local print queues you open your printer setup tool but for printer administration you have to open your browser.

To make this easier the Printing Working Group (PWG) has introduced the IPP System Service standard. This is an interface made up of standardized IPP requests to poll printer capabilities and configure the printer as needed. Every printer from every manufacturer uses the same requests and so a common printer configuration interface can be added to printer setup tools or automated administration with scripts is possible.

The student's task will be to create an appropriate printer configuration interface for system-config-printer or for the GNOME Control Center.

Mentors: Upstream developers of GNOME/GTK or system-config-printer TBD.

Desired knowledge: C and/or Python programming, GTK

Code License: GPL 2+ or LGPL 2+

Driverless printing was originally designed for network printers, a client device, typically a smartphone, tablet, or IoT device) discovers printers nearby via DNS-SD and then communicates with them via Internet Printing Protocol (IPP), which is based on the HTTP web protocol. Printers even use HTTP in addition to IPP, for their administration web interfaces. For more security many printers support also the encrypted versions of these protocols, HTTPS and IPPS.

Not only network but also USB printers support driverless printing. A former standard USB protocols for printers allowed only raw job data to be submitted to the printer, IPP-over-USB got introduced, a new USB standard protocol for printers where data is transmitted as packets (like on the network) and the printer understands IPP also through this channel.

To make these printers working with CUPS with a minimum of needed code and without duplication large parts of the CUPS code, but also to fulfill the IPP-over-USB standard, we have a daemon which emulates an IPP network printer on localhost, but on a port not already used by CUPS (e. g. 60000). The daemon registers the printer also on Avahi, so that it gets advertised on the local machine and network-printer-supporting system infrastructure as cups-browsed and CUPS create a print queue fully automatically.

This daemon is [ippuasbxd](https://github.com/OpenPrinting/ippusbxd) from [OpenPrinting](https://github.com/OpenPrinting/ippusbxd). It works as it should do, conforming to the IPP-over-USB standard, with one exception: There is no encrypted communication support (IPPS/HTTPS).

The task of the student here is to add encrypted communication support to ippusbxd, for both IPPS and HTTPS.

Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD

Desired knowledge: C programming, CUPS, HTTP(S), encryption

Code license: Apache 2.0

Sometimes you browse through your files and see some files which you want to print, files in completely different formats: PDFs, photos, LibreOffice files, … It is awkward to double-click each file, one-by-one, to get it opened in its application, and then click “Print” in each application. It would be much easier to mark all these files, right-click and then click “Print” in the context menu.

Here the student's task is to add this functionality to a popular file manager, for example the one of GNOME.

Mentors: Aveek Basu (basu dot aveek at gmail dot com), upstream developers of GNOME/GTK TBD.

Desired knowledge: C programming, GTK

Code License: LGPL 2+

ipptool is a command line tool for issuing IPP requests and receiving the printer's/the server's answer. This tool is maintained as free software in the ippsample collection from the Printer Working Group (PWG). It is mainly for development and debugging of IPP-related software.

It is also used by the software of the PWG's IPP Everywhere self-certification program, with which printer manufacturers can test their printers whether they comply with the IPP Everywhere standard for driverless printing.

The student's task is to write additional ipptool scripts for coverage of operations and attributes that are required by IPP Everywhere, but not yet tested in the IPP Everywhere Self-Certification process - also new scripts for other IPP specs (e.g., IPP Shared Infrastructure) for developers.

Mentors: Ira McDonald (blueroofmusic at gmail dot com), Printing Working Group, TBD

Desired knowledge: C programming, IPP

Code License: Apache 2.0

The PWG Raster format is a universal, multi-page raster format, supporting various color spaces and color depths, and near arbitrary resolutions and page sizes and also printing-related meta data, like paper type, duplex, … It is designed as a universal raster-based Page Description Language (PDL) which allow all types of printers having a common input data format. As this format is raster-based it does not need high amounts of memory and computing power in the printer for rendering the pages and can therefore be implemented also in very cheap printers.

Together with DNS-SD for the printers to advertise their presence in a local network, and the Internet Printing Protocol (IPP) to not only receive jobs and tell about the status of them but also to tell about the printer's complete capabilities on request one can easily implement driverless printing (PWG Raster is used by the IPP Everywhere, Wi-Fi Direct, and Mopria standards), meaning that there is no printer-model-specific software or data (aka “driver”) needed on the client, the client gets all info from the printer, and the printer has a known language for the job data: PWG Raster (and some others).

To make driverless printing reliably working, clients need to generate correct PWG Raster data streams. To assure this testing software is needed, a so-called “PWG Raster lint” program. It takes an input PWG Raster document file and checks its structure and reports any errors, warnings, or issues with the document's structure or content. This could be used by an “ippserver” tool (IPP printer emulator) as a command to process the input files, which could then report on structural problems with the document content submitted with a Job, and report its status accordingly.

Mentors: Smith Kennedy (smith dot kennedy at hp dot com), HP, TBD

Desired knowledge: C programming, IPP

Code License: Apache 2.0

ippserver is a simple daemon which emulates an IPP printer. It has a lot of possibilities to configure it to emulate the desired printer, it can even emulate real printers using an appropriate spec sheet, which can be extracted from the real printer by a bug-reporting user and the client software developer can emulate the user's printer.

This tool is part of the free software ippsample collection from the Printer Working Group (PWG), a group of printer manufacturers and operating system vendors who have developed the Internet Printing Protocol (IPP) and many other printing-related standards.

The student's task here is to enhance ippserver to support the full range of IPP data types (especially complex data types like “1setOf (textWithLanguage)” and handling the strings being wrapped in single / double quotes, etc. This is important to make ippserver emulate any existing, standard-conforming IPP printer.

Mentors: Smith Kennedy (smith dot kennedy at hp dot com), HP, TBD

Desired knowledge: C programming, IPP

Code License: Apache 2.0

The OpenPrinting project “Common Print Dialog Backends” provides a D-Bus interface to separate the print dialog GUI from the communication with the actual printing system (CUPS, Google Cloud Print, …) having each printing system being supported with a backend and these GUI-independent backends working with all print dialogs (GTK/GNOME, Qt/KDE, LibreOffice, …). This allows for easily updating all print dialogs when something in a print technology changes, as only the appropriate backend needs to get updated. Also new print technologies can get easily introduced by adding a new backend.

For quickly getting this concept into the Linux distributions we need the following smaller, but important tasks to be done:

1. The CUPS backend tells the print dialog only about printer-specific user-settable options, not about general options implemented in CUPS or cups-filters and so being available for all print queues. These are options like N-up, reverse order, selected pages, …As they are only common for CUPS and not necessarily available with other print technologies like Google Cloud Print, they should get reported to the print dialog by the CUPS backend.

2. A print dialog should allow to print into a (PDF) file. This should be implemented in a new print dialog backend.

3. As it will take time until GTK4 with its new print dialog is out, we should get support for the new Common Print Dialog Backends concept for the current GTK3 dialog. As this dialog has its own backend concept one simply would need an “adapter” backend to get from the old concept to the new, common concept.

These are three smaller projects, so we expect that one student will do them in this Summer.

Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD

Desired knowledge: C programming, CUPS

Code license: MIT

The Qt Print Support framework should be updated with the CPD support. The goal is to provide the CPD GUI features and d-bus communications with the CPD backend support for printing from Qt5 applications on support platforms.

Based on the GSoC work of the previous year, one example of Qt CPD implementation outside of Qt Print Support can be found at: https://github.com/rithvikp1998/CPDv2. For this task, the implementation is expected to start with QPrintDialog instead.

Mentors: Dongxu Li (dongxuli2011 at gmail dot com), Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD

Desired knowledge: Cprogramming, Qt, CUPS Licenses: Qt Contribution Agreement =====12. Turn the scp-dbus-service of system-config-printer into C===== system-config-printer was the default printer setup tool in Red Hat/Fedora Linux for a lot of time and also got adopted by Ubuntu around ten years ago. During this time it received a lot of development work, especially on the algorithms for finding the best driver for a printer and for identifying whether printer discovery results from the CUPS backends actually come from the same physical printer. To make these algorithms available for other printer setup tools (both interactive GUI tools and programs which fully automatically create print queues without user interaction) they got moved into a D-Bus service, scp-dbus-service. Now every other program can simply call the needed function via a D-Bus API. The printer setup tool in the GNOME Control Center for example works this way. system-config-printer was written in Python and therefore scp-dbus-service is also written in Python. This makes it depending on Python and also makes it loading the needed Python libraries into memory when started. This can cause delays during boot when a utility to auto-setup print queues is used.Also most printer setup tools are written in C, Therefore it makes sense to convert the D-Bus service into the C language. The student's task is to turn the scp-dbus-service of system-config-printer into C, either as D-Bus service (would work out-of-the-box with many GUIs) or as a C library with API (simpler), ideally both. This will make it easier to write printer setup tools in practically any programming language. Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), system-config-printer upstream developers TBD Desired knowledge: C/C++ programming, Python programming Code license: GPL 2+ or MIT =====13. Google Cloud Print: Desktop-integrated solution for registering local CUPS printers===== [[https://developers.google.com/cloud-print/docs/overview Google Cloud Print]] is a service from Google which allows to print from anywhere with internet access to anywhere else with internet access, for example from a mobile phone to printer at home or in the office. To do so, one needs a Google account and there one registers one's printers so that they can accept jobs sent into the print facility of this Google account. On Linux there is already a way to share the local CUPS printers into Cloud Print: The Chrome/Chromium Browser. In its settings you can activate Google Cloud Print and the local queues get registered. The Browser even leaves a user daemon running when one closes it to continue keeping the printers available for Cloud Print. The disadvantage of this is that the functionality is bound to a web browser, so it is awkward for people who use Firefox for example. Do not suggest now to make the CUPS daemon (daemon which handles the print jobs) or cups-browsed (daemon which browses the network for printers and automatically creates local queues for them) registering the printers, as they are system-wide services and Google Cloud Print is based on the user's Google account, and so something which belongs to a single user. What is needed is a user daemon which starts when logging in and stops when logging out, running with the rights of the user, connecting to the user's Google account registering the local CUPS printers the user is allowed to print on. It will need integration with the desktop for starting and stopping the daemon and for configuration in the desktop's settings utility. Ideally it should work with the GNOME desktop using GNOME Online Accounts and the GNOME settings manager. Google documentation for printer registration. Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Ubuntu/GNOME GUI developers TBD Desired knowledge: C/C programming, GUI programming, GTK

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.

Two of the filters, pdftoraster, to rasterize PDF files into CUPS/PWG Raster, and bannertopdf, to generate banner pages and test pages, use Poppler but make use of unstable APIs of Poppler, requiring frequent modifications when Poppler gets updated. bannertopdf does even not require a PDF interpreter, so it could be implemented with libraries like QPDF.

The task for the student is here to once improve pdftoraster's interface with Poppler and second to convert bannertopdf to use QPDF.

Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com),

Desired knowledge: C and/or Cprogramming Code License: MIT =====15. Foomatic: Generating CUPS PPD generator (/usr/share/cups/drv/*.drv files) from Foomatic data===== CUPS has two mechanisms for on-the-fly-PPD generation to avoid the wasting of disk space by thousands of uncompressed (or slightly compressed) PPD files. One is to put an executable file into the /usr/lib/cups/driver/ directory which lists and generates PPD files on request, the other is using *.drv files in /usr/share/cups/drv, which contain the data for the PPDs in a simpler and more compact format. The former method is deprecated upstream and can be removed in a future release of CUPS, especially also because the executables can get slow in some cases. The latter is not yet supported by Foomatic and letting Foomatic support it is subject of this project idea. The student's task is to create a utility which generates *.drv files from the whole database and/or from selected, printers, manufacturers, drivers, groups, ..., depending on what the user requests. Mentor: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com) Desired knowledge: Perl programming, perhaps also MySQL Code License: GPL =====16. 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/%7Eajohnson/cairo/log/?h=color-space 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 (hughsient at gmail dot com) =====17. 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, Project Leader OpenPrinting (till at linux dot com) Desired knowledge: C and/or C programming

Code License: GPL