Main GSoC Linux Foundation page: How to apply, deadlines, other workgroups, ...

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 dot dev (Instructions)

Telegram: OpenPrinting Channel

Mastodon/Fediverse: #OpenPrinting

Our code repositories: OpenPrinting GitHub

What is OpenPrinting? How did it all begin? What did we achieve? What are we currently doing?

Keep in touch with OpenPrinting's state of the art.

Code License: See project descriptions. Most of our own projects are Apache 2.0 (CUPS, libcupsfilters, libppd, PAPPL, pappl-retrofit, PDFio, …) and some are MIT (CPDB), but we mentor also contributions to other projects, like GNOME, KDE, LibreOffice, … which have their own licenses.

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).

• Destination Linux: Till Kamppeter and Michael Sweet about the history of OpenPrinting
• Ubuntu Indaba: Till Kamppeter and Michael Sweet about the New Architecture
• Ubuntu Office Hours: Till Kamppeter and Aveek Basu about the Google Summer of Code
• Ubuntu Summit 2022: Till Kamppeter hosting an OpenPrinting panel with Zdenek Dohnal, Johannes Meixner, Aveek Basu, and Deepak Patankar
• Ask Noah: Till Kamppeter on how OpenPrinting improved printing with Linux/Unix
• Linux Saloon: Till Kamppeter about how he got Snap enthusiast

• OpenPrinting - We make printing just work! Till Kamppeter, FOSDEM 2024, Brussels, Belgium

OR The New Architecture (What it is, Video)

CUPS, printing environment used by Linux and most other non-Windows operating systems, supports the different printer models with the help of printer drivers, consisting of PPD (PostScript Printer Description) files to describe the printer's capabilities, filters to convert the incoming print jobs into the printer's native language, and sometimes also backends, to support non-standard communication protocols between the computer and the printer hardware.

Modern printers do not need printer drivers (printer-model specific software or data) as they use standard methods for everything: DNS-SD to advertise themselves in the network, IPP (Internet Printing Protocol, at least version 2.0) as a communication protocol with which the printer cannot only print and inform about its status but also provide a complete description of its capabilities, and known standard PDLs (Page Description Languages). These are driverless IPP printers following the IPP Everywhere, Apple AirPrint, Mopria, and/or Wi-Fi Direct Print standards. So printer drivers are only needed for specialty printers or legacy printers.

See also the Debian documentation about driverless printing with CUPS.

We are also moving to sandboxed packaging in modern operating system distributions, where applications are completely isolated from each other, having their own file systems and well-defined paths and interfaces to communicate with other applications.

And already several years ago we moved from PostScript to PDF as standard data format for print jobs.

All this made us rethink how printer drivers should look like. Michael Sweet has already deprecated PPD files more than a decade ago, when we switched to PDF-centric printing (and the PostScript format is also not developed any more by Adobe), but due to lack of a replacement we have continued using them. Some years ago Michael Sweet introduced the concept of Printer Applications as replacement for the classic CUPS printer drivers.

A Printer Application is nothing else than a daemon which emulates a driverless IPP (at least IPP Everywhere) network printer. It advertises itself, speaks IPP, and understands standard protocols as an actual network printer, and even has an administration web interface. Internally, it converts the incoming jobs to the printer's native, often proprietary PDL and sends them off to the physical, non-driverless printer on USB, parallel port or with any network protocol like LPD or raw socket (port 9100). The capabilities which the Printer Application reports on IPP requests or in its DNS-SD record are the capabilities of the printer.

This solves many problems:

• No use of the obsolete PPDs any more
• For CUPS (or any other printing environment) driverless IPP printers and Printer Applications behave the same, no printer driver support needed any more
• If CUPS is in a sandboxed package (like the CUPS Snap) it is not possible to install classic CUPS drivers, as an external program cannot access CUPS' directories for PPD files, filters, and backends. The Printer Application only communicates with CUPS via IP, as a network printer, so CUPS can be sandboxed.
• Printer Applications themselves can be sandboxed, so they can be distributed as OS-distribution-independent packages on a central download place (like the Snap Store). This reduces the development and testing cost for the printer manufacturers a lot.

Now we already have retro-fitted practically all of the classic printer drivers, which are available as free software and come with typical distributions like Debian, into Printer Application Snaps which are available in the Snap Store.

And for many label printers we have already a native (no retro-fit from classic driver) Printer Application: LPrint.

In less than 1 year from now, CUPS 3.x will be released and this is the first CUPS which has dropped PPD and printer driver support, requiring Printer Applications. See the roadmap.

Having multi-function printers in mind (printer, scanner, also often fax in one device) the IPP Scan standard got created, which allows the use of IPP for both printing and scanning. Especially driverless scanning is possible using the same principles as with driverless printing. Manufacturers actually use eSCL and WSD for driverless scanning instead (also supported in free software), all these protocols help to get scanning working in environments of only sandboxed packages and to more easily distribute scanner drivers.

Currently, SANE is the standard platform for scanning. Here a frontend, for example a GUI user application, like simple-scan or X-SANE, looks for backends (scanner drivers) which are supplied as dynamically loadable shared libraries in a given directory, runs each backend so that it returns back which of its supported scanners are currently present, having the frontend end up with a list of all currently available scanners and through which backend they are available.

This architecture is not viable for sandboxed packaging, where the user applications are in separate sandboxed packages and one wants to be able to add scanner drivers, preferably each scanner driver also in a sandboxed package.

So as we create Printer Applications we create Scanner Applications emulating a driverless IPP scanner using any of the above-mentioned driverless scanning standards. We have settled on eSCL for this currently, as it is the most-used standard by the scanner industry and its specification is publicly available. Now scanner drivers can be distributed in individual sandboxed packages, OS-distribution-independent, and for multi-function devices one can even distribute a combined Printer/Scanner Application. The sandboxed packages of user applications which scan only need a backend for IPP Scan and this discovers all Scanner Applications (and scanners in native network devices).

So we are going to replace SANE in the role of an interface between scanning user applications and scanner drivers by the sandboxing-ready eSCL. SANE will continue to exist, but to provide the legacy scanner drivers enclosed in a Scanner Application.

Work on extending the Printer Application framework PAPPL has already been started in GSoC 2021 and continued in GSoC 2022 and 2023.

Most print jobs are created from desktop applications. Users create printable documents with applications like LibreOffice or GIMP, they receive documents by e-mail, want to print web content which they see in their browsers, … Therefore working support for printing in desktop environments is essentially important.

There are two types of user interfaces needed. One is the print dialog which pops up when printing out of an application. It allows to choose on which of the available printers to print and to control details of how the content gets printed, like paper type and size, print quality, double-sided printing, … The second interface is the printer setup tool, for finding and configuring printers to make them available for printing, and to se useful defaults for the most common printing tasks.

This functionality is usually available for all desktop environments and applications, but with the New Architecture we need to change it, because print destinations are now defined differently.

Up to CUPS 2.x a print destination was defined by a CUPS queue, defined in the printers.conf configuration file of CUPS, consisting of a name under which the queue is identified, a device URI which defines the way how to access the printer hardware, and the PPD file telling about the driver to use and the capabilities of the printer.

This is not needed any more for modern, driverless IPP printers and CUPS has already started to support them explicitly in the 2.x generation. For the New Architecture a print destination is an IPP print service, advertised via DNS-SD and all needed information to print on it can be retrieved by IPP.

For print dialogs we separate the GUI and the communication with CUPS into separate frontend (print dialog) and backend (CUPS communication) using the Common Print Dialog Backends. So the CUPS backend is maintained by OpenPrinting, as CUPS itself, meaning that it will always keep pace with the development of CUPS, and changes in CUPS, like the New Architecture, will go into it right away. By this we only need to take care that all existing print dialogs (GNOME/GTK, KDE/Qt, Mozilla (Firefox/Thunderbird), Chromium Browser, LibreOffice) get CPDB support.

Printer setup tools (GNOME Control Center, KDE Settings, system-config-printer) need to list IPP print destinations on their main view, and give appropriate configuration options on them to the user, especially a button to quickly open the web admin interface, also the destinations should get listed in logical groups,to have printing and fax out of a multi-function device together, or the printers supported by the same Printer Application.

Also the “Add Printer” part of the printer setup tools still makes sense.It has to list non-driverless printers and assign Printer Applications instead of PPD files to them.

Actually we will not remove the old functionality from the printer setup tools and replace it by the new on. Instead, we add the new functionality so that the tool works with any CUPS version, and in the case of CUPS 2.x they will then handle both permanent CUPS queues with PPD files and IPP print destinations which CUPS can print on without needing to create a queue. This way distributions will be able to switch to CUPS 3.x at any time and no synchronous switch of both CUPS and the printer setup tool(s) is required.

Parts of this work got already done, especially most of the “Printers” module in GNOME Control Center by Mohit Verma during GSoC 2022 and 2023, CPDB support in the GTK print dialog and most of the CPDB support in the Qt print dialog by Gaurav Guleria in GSoC 2022 and CPDB support for the print dialog of the Chromium Browser by Kushagra Sharma in GSoC 2023.

For a smooth transition to CUPS 3.x in all distributions we need to add support for the New Architecture in all desktop environments and all applications. Especially if we want to switch Ubuntu to CUPS 3.x we cannot only take GNOME into account, as the core of the Ubuntu distribution is also used by the 10 official, community-maintained flavors which cover a wide range of desktops. Therefore we were not able to switch Ubuntu 23.10 to use the CUPS Snap.

At least what we are doing on the coding side is to move the architecture of Printer and Scanner Applications and the support for sandboxed packages for printing and scanning forward. Especially we want to get printing and scanning “just work” also in completely sandboxed OS distributions and allow printer and scanner hardware manufacturers to provide drivers as distribution-independent, easily downloadable and installable packages.

This principally happens in the following projects:

• CUPS - The standard printing environment for Linux and other POSIX-style operating systems
• cups-filters - filters, backends, cups-browsed, … - Everything which CUPS needs to be used on non-Mac systems
• CUPS Snap - Snap package of CUPS, for printing in all-Snap OS distributions (in the Snap Store)
• PAPPL - Printer Application Framework - Library for Printer/Scanner Applications
• pappl-retrofit - PPD/Classic CUPS driver retro-fit Printer Application Library
• PostScript Printer Application - Printer Application for PostScript Printers (in the Snap Store)
• Ghostscript Printer Application - Printer Application for printers using Ghostscript (and many other) drivers (in the Snap Store)
• HPLIP Printer Application - Printer Application for most HP Printers (in the Snap Store)
• Gutenprint Printer Application - Printer Application for high-quality printing on Epson, Canon, and other inkjets and on many dye-sublimation printers (in the Snap Store)
• LPrint - Printer Application for label printers (in the Snap Store)
• sane-airscan - The “airscan” SANE backend, supports driverless eSCL and WSD scanning, IPP Scan support is planned
• ipp-usb - IPP-over-USB - Support for driverless printing via USB (in the Snap Store)
• Common Print Dialog Backends Libraries - Libraries implementing the Common Print Dialog Backends (CPDB) concept
• Common Print Dialog Backends CUPS Backend - Backend to print with CUPS from all CPDB-supporting print dialogs

See also

• All about OpenPrinting - How it started, what we achieved, and what we are doing
• OpenPrinting News and Events - Monthly news post, software releases, …
• OpenPrinting mailing list archive - Our recent discussions about the development of the printing architecture

1-2 contributors full-size (350 hours), Level of difficulty: Hard

Most print jobs are sent via the print dialog of a desktop application, like evince, Chrome, LibreOffice, DarkTable, … Print dialogs are usually, like “Open …” or “Save as …” dialogs, provided by the GUI toolkits, in most cases GTK or Qt, sometimes applications come also with their own creations, like LibreOffice or Firefox.

Problem here is usually not the design of the dialog itself, most are actually easy to use, but the way how they connect to CUPS (and also to other print technologies) and how well this connection code is maintained and kept up-to-date.

GUI toolkit projects are large projects, often with long release cycles and all with a certain inertia, and there are things which many people are eager to work on, and others, like print dialogs, which have to be there but no one is really motivated to push their development forward and do the needed maintenance work.

An important part of the maintenance of a GUI toolkit is that it interfaces well and correctly with the underlying operating system, graphics, sound, storage, …, and printing! The OS is under continuous development, things are changing all the time, components get replaced by others, printing is CUPS for 23 years, but within CUPS we have also changes, and they need to be taken care of in the print dialogs.

Several years back, CUPS started to create temporary queues for driverless IPP network printers (or remote CUPS printers, which are emulations of IPP printers), which are only physically available when they are accessed (capabilities are polled or job printed). Print dialogs used an old API which did not support this, the temporary queues did not appear in the dialog, a helper daemon, cups-browsed had to convert the temporary queues into physical queues as a workaround. The correct solution had been to change the print dialogs to a newer CUPS API which supports these queues, but no one at the GUI toolkit projects has felt responsible and taken the time for this update for many years. Only recently this got fixed.

This made me introducing the Common Print Dialog Backends (CPDB) back in 2017, a de-coupling of the print technology (CUPS, print-to-file, that time also Google Cloud Print) from the GUI. The GUI projects have to adopt the CPDB support only once and then OpenPrinting (or any upcoming cloud printing projects) takes care of the CPDB backend for the print technologies to be up-to-date with any changes. This way print technology projects can react quickly and are not dependent any more on the GUI toolkit’s inertia.

The print dialogs of the major GUI toolkits, GTK, Qt, got CPDB support added in GSoC 2022, but several applications come with their own creation of a print dialog. AFAIK these are Firefox/Thunderbird (Mozilla), Chromium/Chrome (Google), and LibreOffice. Also these dialogs need to get CPDB support to make CPDB universal.

Then we are especially prepared for the switch to CUPS 3.x which does not support PPD files any more, as the CUPS backend of CPDB is already using only CUPS APIs not handling PPD files. And we are also prepared for IPP infrastructure/cloud printing for which we also want to create a CPDB backend (see below).

The contributor's task is to get CPDB into the print dialogs upstream, the UI of them does not need to be changed. Dialogs to be treated are Mozilla for Firefox and Thunderbird, and also LibreOffice, and any other application-specific dialog if we have missed it by now. For LibreOffice there was already worked on CPDB support back in 2017, but in the meantime things have changed and the dialog needs to get updated, especially for the new features of CPDB 2.x (human-readable strings/translations, option groups, …).

CPDB support for the print dialog of the Chromium Browser is already done by Kushagra Sharma in GSoC 2023.

For the CPDB integration we do not need UI design work.

Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Gaurav Guleria (gaurav dot gen3 at gmail dot com), Firefox/Thunderbird/Mozilla developers, LibreOffice developers, TBD

Desired knowledge: C/C++, GTK or Qt, DNS-SD/Avahi, CUPS/IPP

Code License: MIT, GPL-2+ and LGPL-2+

1 contributor full-size (350 hours), Level of difficulty: Intermediate

Originally, we already had discontinued the development of system-config-printer and put it into maintenance mode, only fixing bugs and collecting UI translations.

But system-config-printer s still used a lot. There are practically only 3 printer setup tools around: The “Printers” module of GNOME Control Center, the printer manager of KDE Settings, and system-config-printer. There are many more desktop environments than just GNOME and KDE, and distributions using many of those use system-config-printer as their printer setup tool.

For switching distributions into the New Architecture, meaning from CUPS 2.x to CUPS 3.x, the printer setup tool needs to get appropriately adapted, to list IPP print destinations with appropriate configuration options, especially access to their web admin interfaces, and assign Printer Applications to non-driverless printers.

One could also think about dropping the concept of printer setup tools altogether as modern, driverless printers are simply there, but it is not very intuitive for a user to have to find a Printer Application and install it to make a non-driverless printer working and that for driverless printers and Printer Applications there are web admin interfaces and how to access them.

So to assure continued coverage of all desktops we need to revive development of system-config-printer and make it supporting the New Architecture, but as with GNOME Control Center and KDE Settings we also need to keep the old functionality, to allow a switchover to the new CUPS at any time and already while still using CUPS 2.x, have a better support for driverless printers.

And this is the contributor's task in this project.

Note that system-config-printer is written in Python.

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

Desired knowledge: Python, C, CUPS

Code License: GPL-2+ (GPL 2 or any later version)

1 contributor full-size (350 hours), Level of difficulty: Hard

From version 2.5.x on CUPS uses OAuth2 (Open Authorization) for authorization purposes and drops the formerly used Kerberos with the CUPS 3.x generation. See latest state-of-the-art presentation from Michael Sweet: slides, video, slide 11).

Authorization in printing is needed to once protect the data of confidential jobs, and second, to protect printer resources, like toner or paper.

OAuth2, standard for authorization for internet services (“Log in with Google”) is also used as authorization standard for IPP (Internet Printing Protocol) printing.

As described in a talk on the OpenPrinting microconference on Linux Plumbers 2022 (slides, video) when accessing an IPP printer requiring authorization, it returns the URL to request the authorization from the authorization server in the response to the get-printer-attributes IPP request. Now the print client (print dialog, printer setup tool) has to open the URL in a browser so that the user can log in, create an account, or whatever the authorization server needs to identify the user. On success the server returns a URL with authorization code with which the client can get the access code to the printer.

This works for all kinds of IPP print destinations which require authorization, not only physical network printers but also print servers and IPP-based cloud printing services.

The contributor's task is to add the functionality to open the authorization server URLs and to supply the access code to the printer to the desktop printing workflow. This can be implemented in print dialogs or perhaps even made independent of concrete print dialogs by the CPDB backend for CUPS triggering a D-Bus service for opening the URL (perhaps desktops always have such a thing?). Investigating what the best solution is for this task is part of the project.

Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Gaurav Guleria (gaurav dot gen3 at gmail dot com), TBD

Desired knowledge: C/C++, GTK or Qt, DNS-SD/Avahi, CUPS/IPP

Code License: Apache 2.0, MIT, GPL-2+ and LGPL-2+

1 contributor full-size (350 hours), Level of difficulty: Intermediate

OSS-Fuzz is a project aimed at finding vulnerabilities in open-source projects that are critical to the Internet infrastructure. It is powered by Google and was initiated in response to Heartbleed, an OpenSSL vulnerability that could have been discovered with classic vulnerability discovery techniques. The codebases integrated into OSS-Fuzz are run multiple times with randomly crafted inputs in an approach called fuzzing.

Most of OpenPrinting's code is written in C, which is susceptible to memory corruption bugs. OpenPrinting's projects do not use fuzzing, with a single exception: CUPS has a custom fuzzer run when testing the build, for a fixed number of iterations.

Due to the compatibility of C projects with OSS-Fuzz, we would like to abandon the existing fuzzer and integrate the following C-based OpenPrinting projects into OSS-Fuzz (projects in priority order):

• CUPS
• libcups
• cups-local
• cups-sharing
• libcupsfilters
• cups-filters
• cups-browsed
• PAPPL
• cpdb-libs
• cpdb-backend-cups
• libppd
• pappl-retrofit

The purpose is to use the Google Summer of Code timeframe to create a mature OSS-Fuzz integration that maximises the number of fuzzed projects and fuzzing efficiency, as measured by coverage and execution speed.

The contributor should work on:

• Coordinating with OpenPrinting which projects have highest priority and also which functionality of them, to get the best from the limited GSoC time
• Creating Docker-based build environments
• Writing libFuzzer fuzz targets
• Creating a corpus of data
• Understanding and implementing the OSS-Fuzz best practices
• Coordinating with the OpenPrinting developers to patch the vulnerabilities found by OSS-Fuzz
• Analysing the found vulnerabilities and interpreting their details to deduce vulnerability classes that can be mitigated in bulk.

Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), George-Andrei Iosif, Security Engineer at Snap Inc. (hi at iosifache dot me).

Desired knowledge: C, fuzzing

Code License: Apache 2.0, MIT (licenses of the OpenPrinting projects)

1 contributor full-size (350 hours), Level of difficulty: Intermediate

Immutable desktop operating system distributions are currently one of the most talked about subjects in free software. There is barely passing a week where one does not hear about any new distribution of this kind.

Immutable distributions are made up of a read-only (immutable) core file system and applications are installed also as immutable container images. This gives more ease of use, reliability, and security, as the file systems cannot be modified and messed up, but instead, only replaced and updated as a whole, and also each application is in its own security capsule not being able to access any of the other applications or the system. This practice is commonplace on smartphones and got overtaken to PCs.

On most immutable distributions, one installs desktop applications in the Flatpak format. This gives a huge choice of apps, but Flatpak cannot be used for GUI-less system applications and daemons. The solution for adding this type of software is the use of an alternative container format. And here OCI containers are the solution. The container images can be downloaded from app-store-alike services like the Docker Hub and be installed an run via Docker, podman or similar.

If you have a look at the Docker Hub you will find several container images for CUPS, but none of them is the official one, none of them comes from OpenPrinting. This makes the choice difficult, to find the most suitable one and also not get hit by a malicious one. So an official OCI container of CUPS is the first thing we need, to be able to have always the latest release of CUPS, directly from its developers.

Another point is how to add printer and scanner drivers to immutable distributions. For this we also need containers of Printer and Scanner Applications.

The contributor's task is to create these containers and infrastructure and scripting to ease their maintenance, like for example update automation when for one or another of their components a new upstream version is released, or for automated test building and testing.

There are tools for creating such images, for example rockcraft which uses build instruction files similar to Snap (see this workshop: slides, video) and so we can use our CUPS Snap as base, but we will not require the contributor to use a special, given tool.

Desired knowledge: Shell, Python, packaging, immutable OS distributions, GIT

Code License: Apache 2.0, MIT (licenses of the OpenPrinting projects)

1 contributor full-size (350 hours), Level of difficulty: Hard

Like CUPS, libcupsfilters is principally written in regular C and not in C++. We want to avoid C++ as it has often problems with binary compatibility and the mechanism with which the Debian/Ubuntu build services auto-detect dependencies between Debian packages get very awkward with C++.

But libcupsfilters still depends on one library which is written in C++, QPDF, a library for manipulating PDF files: Scaling up and down, moving around on the page, rotating, combining several source pages on one destination page, turning filled PDF forms into straight PDF, … QPDF is used by the filter functions cfFilterPDFToPDF(), cfFilterBannerToPDF(), cfFilterGSToRaster(), and cfFilterRasterToPDF().

Michael Sweet, author of CUPS, has some years ago started the PDFio project. This is a PDF handling and manipulation library, as QPDF is, but it is fully written in standard, regular C, not in C++.

Therefore we want to replace the use of QPDF by PDFio and this is what this GSoC project is about.

But for such a switchover we must take into account that QPDF is a complex and sophisticated project with a lot of features (it got even new features by two GSoC projects of OpenPrinting) while PDFio is a young project run as one of the many small projects by Michael Sweet and we must be very careful to see whether it does not miss any important feature. Especially we must look after correct printing of filled-in PDF forms and PDF annotations.

So part of the project will be investigation of suitability and perhaps also work with Mike to get needed features added. And after the switchover thorough testing is needed to avoid any regressions after this impactful change.

Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Michael Sweet, author of CUPS and PAPPL (msweet at msweet dot org), Ira McDonald (blueroofmusic at gmail dot com), TBD

Desired knowledge: C/C++, CUPS

Code License: Apache 2.0

1 contributor full-size (350 hours), Level of difficulty: Intermediate

cups-browsed is a helper daemon for CUPS to automatically set up network printers. In the beginning it was to overcome that when CUPS from 1.6.x on used DNS-SD instead of its own browsing/broadcasting, it did not auto-setup client queues any more.

With the time it got lots of more functionality: Legacy CUPS browsing/broadcasting for interoperability with CUPS 1.5.x and older (often in long-term support enterprise distros), clustering, manually and automatically, also for clusters of printers of completely different types, user has one “universal” print queue and by their option settings job goes to the correct printer. Also filtering lists of many printers is supported, and everything can be configured/fine-tuned by the user or admin.

With CUPS already having its temporary queue functionality for network printers without need of explicit manual setup, and the Common Print Dialog Backends getting into the print dialogs and talking to CUPS with modern interfaces, we do not need automatic queue creation for network printers any more, but the other functionality of cups-browsed is still very useful.

So we do not want to discontinue cups-browsed, but take it into the New Architecture of printing, giving it the appropriate modern interface. Currently cups-browsed discovers printers via DNS-SD, and then creates (or not creates) local print queues pointing to them according to the rules in its configuration file. But currently it creates classic CUPS queues, with PPD files generated according to the printer's IPP attributes. What we need is make it working with CUPS 3.x, which drops PPD files and classic printer drivers.

For this we want tom turn it into a Printer Application, the new printer driver format, emulating a driverless IPP printer. This way CUPS can access the printers created by cups-browsed and create temporary queues for them on-demand. Internally we define with configuration file what these queues should do: Clusters, retro-fit to old CUPS, …

The contributor's task is to implement this transition, using PAPPL for all standard elements of a Printer Application, like daemon, IPP parser, web admin interface, … They will make cups-browsed create a queue in the Printer Application if appropriate destination printers get discovered, and remove it when these printers disappear (turned off, user leaves network, …). CUPS will simply pick up on the emulated IPP printers then. And there will be a web interface to be created, for the configuration of the clusters, filter rules, …. one does not need to edit cups-browsed.conf manually any more.

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

Desired knowledge: C, CUPS

Code License: Apache 2.0

1 contributor full-size (350 hours), Level of difficulty: Hard

cups-filters currently supports Braille embossers through a series of PPD files and shell scripts that convert documents into a textual layout, convert the text into Braille dots, and convert the Braille dots to braille embosser-specific formats.

For long-term support and wide availability, this needs to be converted to the newer CUPS infrastructure, Printer Applications.

The contributor's task is thus:

• Converting these shell scripts into filter functions in libcupsfilters
• Creating a Printer Application that exposes Braille embossers configuration to users

The contributor does not need to own any specific hardware, a comparison can be made between the output of the existing shell-script-based implementation and the output of the converted implementation.

Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Samuel Thibault, Braille expert (samuel dot thibault at ens-lyon dot org)

Desired knowledge: C/C++, Shell, CUPS

Code License: Apache 2.0

1 contributor full-size (350 hours), Level of difficulty: Hard

Gutenprint is a high-quality printer driver for a wide range of inkjets, especially Epson and Canon, dye-sublimation printers and even monochrome PCL laser printers. It does not only cover many printers to give them support under Linux and free software operating systems at all, but also is optimized for highest possible print quality, so that at least on some printers and with the right settings you can even get better print quality than with the original (Windows/Mac) drivers.

Gutenprint is usually used as classic CUPS driver with a CUPS filter and a PPD file generator. As, as mentioned above, CUPS will not support PPD files any more from version 3.x on and when using the CUPS Snap one cannot install PPD-based drivers already now.

So a Printer Application of Gutenprint is needed. There is already one, but it is a retro-fit of the classic CUPS driver. The Printer Application simply calls the PPD generator and the filter at the right places to do its job.

As Gutenprint contains all its printer support and printer capability info in libgutenprint or in files which are read by libgutenprint, the PPD generator and the filter only containing calls of functions in libgutenprint, it should be easy to create a PAPPL-based, native Printer Application for Gutenprint.

Here on an incoming get-printer-attributes IPP request we call the same functions which the PPD generator calls, but instead of translating the responses into a PPD file we translate it into the IPP answer for the get-printer-attributes request. And when we have a job to print, we call the library functions which the filter calls, but directly.

This does not only save us from resource-consuming calls of external executables but we are also no harnessed by the PPD file syntax and so have more flexibility in the UI representations of the (often more than 100) printer-specific options. Also, generally we should completely do away with the PPDs. Retro-fitting is only an ugly interim solution or for drivers which are not actively maintained anymore and for printers we do not have at hand and so cannot test the drivers.

The contributor's task is thus:

• Create a PAPPL-based Printer Application using the libgutenprint library and PAPPL
• Make sure all options and parameters of the Gutenprint driver are accessible from the Printer Application's web admin interface.
• Package the Printer Application as a Snap

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

Desired knowledge: C, PAPPL, CUPS

Code License: Apache 2.0

1 contributor full-size (350 hours), Level of difficulty: Intermediate

To protect a free software project worked on by several contributors against regressions caused by a committed change, one needs frequent, automated testing of the code, base, ideally triggered by every commit into the repository. This is called Continuous Integration (CI).

What is triggered on each commit is usually some static analysis of the code using common, specialized tools and also build and execution tests, usually doing `./configure; make; make test` on different system platforms.

This naturally requires test scripts/programs which are compiled and run by the `make test` step. For CUPS for example the daemon is started (on an unprivileged port so that it does not need root), queues created and listed, jobs sent, the logs checked whether everything went OK, … For Ghostscript a large collection of input files (gathered from bug reports) is processed and converted into raster formats.

The contributor's task here is to write test programs for the OpenPrinting projects libppd and pappl-retrofit so that `make test` does something useful, being efficient to catch regressions. They should exercise important functionality of the software with different parameters and analyse logs and output files to check whether the program did the expected work.

Test programs are also needed for the so-called 'autopkgtest' tests which are added to Debian packages and executed whenever the package is uploaded to Debian or Ubuntu.

In addition, instruction files and shell scripts are needed to build the software on different platforms/environments, run tests, create GitHub Actions (for the automatic triggering on each commit …).

This subject got discussed on the OpenPrinting micro-conference on Linux Plumbers 2022: (Summary, Slides, Video)

Here you can see what we already have in terms of CI, and what is missing …

Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Michael Sweet, author of CUPS and PAPPL (msweet at msweet dot org), TBD

Desired knowledge: C, Shell, PAPPL, CUPS, CI

Code License: Apache 2.0

1 contributor half-size (175 hrs), Level of difficulty: Intermediate

Scanning with IPP Scan gives the user the possibility to request the scanned image in PDF format. If the IPP Scan server is a Scanner Application, a filter function from cups-filters would convert the the raster image coming from the scanner into PDF.

Now such PDF files are simply raster images in a PDF frame, not high-level graphics with text and fonts, as PDFs produced by office applications are. Especially one cannot search text in a PDF coming from a scanning process.

Ghostscript has a new “pdfocr8” device with which Ghostscript takes raster graphics PDFs (or PostScript files) as input, applies OCR (Optical Character Recognition) to the raster image, and creates a PDF which contains the raster image to visually show the scan but adds data about the contained text and where it is located, so that you can find text with the search facility of a PDF viewer.

Here the contributor's task is to write a filter function (or extend the ghostscript() filter function) to make the “pdfocr8” output device of Ghostscript being used so that a searchable PDF is obtained.

Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Sahil Arora (sahilarora dot 535 at gmail dot com), Dheeraj Yadav (dhirajyadav135 at gmail dot com), TBD

Desired knowledge: C/C++, CUPS

Code License: Apache 2.0