This is an old revision of the document!
Important: We protect the e-mail addresses of our mentors and mailing lists against spam bots. Please replace all occurrences of “ at ” and “ dot ” by “@” and “.” resp.
Mailing list: printing-architecture at lists dot linux-foundation dot org
IRC: #openprinting on Freenode
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).
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+
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
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),
Code License: GPL