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).
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:
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, 2023, and 2024.
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 set 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 one. 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 and by Kaushik Vishwakarma in GSoC 2024, CPDB support in the GTK print dialog and most of the CPDB support in the Qt print dialog by Gaurav Guleria in GSoC 2022, CPDB support for the print dialog of the Chromium Browser by Kushagra Sharma in GSoC 2023, for the Mozilla (Thunderbird and Firefox) print dialog also by Kushagra Sharma in GSoC 2024, and for the LibreOffice print dialog by Biswadeep Purkayastha in GSoC 2024. Biswadeep and his mentor, Michael Weghorn also contributed a lot to CPDB itself. In addition, we have a volunteer, Tarun Srivastava, working on the KDE Print Manager.
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:
See also
NOTE: Further project ideas can get added at any time before the contributor application deadline. The already listed project ideas can get updated, like correcting mistakes and completing information, like the mentor lists.
So please have a look here from time to time …
1 contributor full-size (350 hours), Level of difficulty: Hard
The print dialog of Qt, which is also the print dialog used by KDE applications has still the user interface of 20 years ago, when I told the Qt and KDE developers that a CUPS-supporting print dialog is needed and they made this print dialog in response.
Now, after the internals of the dialog being up-to-date (Support for the Common Print Dialog Backends added in GSoC 2022) we need to make the user interface of the Qt print dialog cute.
The modernization should at least be a UI similar to the one of the GTK print dioalog. This should not require any extensions of the API between the print dialog and the applications and so the new dialog can replace the old one without modifications on existing applications needed.
Optionally, depending on the time left, a dialog with built-in preview (Like in LibreOffice, Chromium, Firefox, Thunderbird) could be created. This requires more UI design work and most probably also additions to the API. The migration of a simple application (like text editor or document viewer) to the new print dialog would demo it and make the developers of other applications switch over.
Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Qt developers, TBD
Desired knowledge: C/C++, Qt, UI Design
Code License: LGPL-3 and GPL-2
1 contributor full-size (350 hours), Level of difficulty: Hard
Are you using LibreOffice, Firefox, Thunderbird, or Chromium with their nice, modern preview-centric print dialogs and got somewhat disappointed with GNOME apps like the Text Editor, Evince, or similar because of their more conventional GTK print dialog? Note that GTK's dialog has also a preview, but it is awkward to use, one has to click a button to get a preview, but there is no button to return to the main dialog to do adjustments.
Then you should make an end to this problem, by modernizing the user interface (UI) of GTK's print dialog!
Investigate the workflow of the modern preview-centric print dialogs and also have a look into their code (the mentioned apps are all open source). Also have a look into the code base of GTK's print dialog. Then design a similar UI, with embedded preview for the print dialog and implement it in GTK.
Try to conserve the API between the application and the print dialog, so that the new print dialog can just replace old one in all applications. If this is not possible, try to keep the API additions a minimum, and for applications which are not (yet) adapted to the new print dialog, try to make as much as possible working in your print dialog (and as last resort display the old dialog).
Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), GTK/GNOME developers, TBD
Desired knowledge: C, GTK/GNOME, UI Design
Code License: LGPL-2 or later and LGPL-2.1 or later
1 contributor full-size (350 hours), Level of difficulty: Hard
As we have made the “Printers” module of the GNOME Control Center supporting CUPS 3.x in several GSoC projects we need to do the same for the KDE Print Manger. And this is what this project is about.
For the local server of CUPS 3.x the main view does not need to display CUPS queues as defined in `/etc/cups/printers.conf` with PPD files any more but instead, it has to display IPP print destinations (driverless network and IPP-over-USB printers, Printer Applications, shared remote CUPS queues) as on all these we can print, without a CUPS queue needing to be created, as CUPS creates a temporary one when needed. The destinations have to be grouped, when they come from the same device, server, or Printer Application, and the IPP destinations are configured by their admin web interfaces, so we have to add buttons to open these interfaces.
The “Add Printer” dialog will continue to exist, but to list non-driverless (legacy or specialty) printers and assign Printer Applications instead of PPD files to them.
Actually we will only add the new functionality and not remove the old one, meaning displaying both IPP destinations and classic CUPS queues, and in the “Add Printer” part allow for assigning both PPD files and Printer Applications (latter preferred), so that once the new Print Manager in place we can make a smooth transition from CUPS 2.x to CUPS 3.x at any time, and also, CUPS 2.x already supports IPP print destinations without permanent CUPS queue, so also for CUPS 2.x users modern, driverless printers will just appear and they do not try to unecessarily create queues for them.
Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Mike Noe (noeerover at gmail dot com), KDE developers, TBD
Desired knowledge: C/C++, KDE/Qt, UI Design
Code License: GPL 2.0 or later and LGPL 2.0 or later
1 contributor full-size (350 hours), Level of difficulty: Intermediate
Most software with print functionality or print administration functionality uses the CUPS library (libcups, 2.x, 3.x) to communicate with CUPS. This is easy when the software is written in C or C++ as the library is written in C.
If the software is written in other languages, we need some connection between the library and the client code, the so-called bindings. For Python we have bindings for libcups, pyCUPS. This works well with libcups 2.x already for years. system-config-printer is principal user of pyCUPS.
What we need now is to extend pyCUPS for the use with libcups 3.x of the new CUPS 3.x, so that pyCUPS will live on and continue to allow writing software which interacts with CUPS in Python.
The contributor's task is to go through the APIs of libcups3 and compare them with libcups2 to see what has to be added. If there is a way to automate the creation of Python bindings, it can be used and old (libcups2) and new (libcups3) has to be merged, so that pyCUPS can be used for any version of libcups.
It should be also taken into account that libcups2 of CUPS 2.5.x got some functions of libcups3 backported.
system-config-printer was already updated for CUPS 3.x in last year's GSoC. Here we want system-config-printer use the new pyCUPS now, for optimization and minimization of code duplication.
Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Zdenek Dohnal, Printing Maintainer at Red Hat (zdohnal at redhat 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
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++.
In libcupsfilters we now succeeded to eliminate use of C++, by replacing the use of the C++ library QPDF for PDF manipulation by Michael Sweet's PDFio and also by not using libpoppler any more but using Poppler's command line utilities instead. This was done as a GSoC project last year.
As the call of Poppler via command line utilities and Ghostscript having a license which makes it unsuitable in vertain cases, we are looking into a PDF rasterizer which is written in straight C and has a more friendly (permissive) license. PDFio is written in C and has the same license as CUPS and libcupsfilters themselves, but it is only a PDF manipulation library, not a renderer.
But as PDFio is able to do the “dirty work” of PDF file reading, especially navigating through the file's object structure we can make use of it to create a PDF renderer, ideally to extend the PDFio library to provide this functionality or to create the renderer library using PDFio.
This renderer should be aimed for printing, it should be principally called from libcupsfilters, or from Printer Applications, so the goal of this project is to get in this direction and not design a fancy GUI document viewer, but a simple screen display facility would be helpful for development and debugging.
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
Security- and AI-related project
1 contributor full-size (350 hours), Level of difficulty: Hard
Recent vulnerabilities (including CVE-2024-47175, CVE-2024-47176, CVE-2024-47177) reported in OpenPrinting projects have underscored the critical need for robust security measures. Given that most of the projects of OpenPrinting are developed in C/C++, which are prone to memory violation bugs. To address these challenges, OpenPrinting has engaged with Google's OSS-Fuzz, a service designed to support open-source communities by providing large-scale fuzz testing and bug reporting, and maintains the fuzz harnesses in the separate OpenPrinting fuzzing repository.
Current Integration with OSS-Fuzz: OpenPrinting has successfully integrated three key projects into the OSS-Fuzz workflow, with two additional projects currently in progress. Although the integration has already yielded significant results, which have reported 21 critical fixed bugs leading to more than 5,000 lines of code fixes, it remains insufficient. The testing coverage for critical components is still lacking, and the severity of potential issues within OpenPrinting projects demands further action.
For now, OpenPrinting has integrated projects into the OSS-Fuzz workflow:
The following projects are under construction:
With Google's introduction of OSS-Fuzz-Gen, which leverages Large Language Models (LLMs) to enhance fuzz testing for open-source software, it has demonstrated exceptional potential in facilitating the integration of high-quality fuzz testing (Google Blog). Therefore, we aim to utilize the OSS-Fuzz-Gen framework to further improve the existing quality of OSS-Fuzz harnesses
Project Goals for GSoC 2025: The primary objective for this Google Summer of Code project is to refine and expand our existing fuzz testing harnesses. Specifically:
Contributor Responsibilities:
Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Jiongchi Yu, PhD Candidate at Singapore Management University (jiongchiyu at gmail dot com), George-Andrei Iosif, Security Engineer at Snap Inc. (hi at iosifache dot me).
Desired knowledge: C, Python, fuzz-testing
Code License: Apache 2.0, MIT (licenses of the OpenPrinting projects)
Security-related project
1 contributor medium-size (175 hours), Level of difficulty: Intermediate
OpenPrinting hosts many polyglot projects, which are developed not limited to languages of C/C++. We also host software written in languages like Python and Golang, which function as crucial printing APIs and often interface with C/C++ libraries to deliver comprehensive printing services. The integration of multiple programming languages into our ecosystem underscores the necessity for a broad and inclusive testing approach. Given the diversity of development environments, it is crucial to extend the testing for these projects, specifically for integration of OSS-Fuzz.
To this end, we plan to extend the capabilities of the existing OSS-Fuzz frameworks to include projects developed in languages other than C/C++. This initiative will target Python and Golang projects, ensuring that our fuzz testing encompasses the full spectrum of development environments within OpenPrinting.
Project Goals for GSoC 2025: The primary objective for this Google Summer of Code project is to integrate the polyglot projects in OpenPrinting into OSS-Fuzz framework and refine existing unit tests for these projects. The targeting projects include:
Contributor Responsibilities:
Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Jiongchi Yu, PhD Candidate at Singapore Management University (jiongchiyu at gmail dot com), George-Andrei Iosif, Security Engineer at Snap Inc. (hi at iosifache dot me).
Desired knowledge: Python, Go, fuzz-testing
Code License: Apache 2.0, MIT (licenses of the OpenPrinting projects)
Security-related project
1 contributor full-size (350 hours), Level of difficulty: Hard
As OpenPrinting advances driverless printing services, the corresponding standardized printing protocols, such as the Internet Printing Protocol (IPP), have become more and more important. The protocol is fundamental to achieving generalized printing services and thus requires rigorous security testing to prevent vulnerabilities.
Effective testing of printing protocols and Domain-specific languages (DSL) like IPP and PostScript demands precise input pairs and well-regulated testing environments/contexts. Given the complexity and technical specifications of these protocols, creating universal testing suites that can be applied across various platforms and languages is essential. Such suites will support the consistent functionality and specification adherence necessary for secure and efficient printing operations.
Project Goals for GSoC 2025: The primary objective for this Google Summer of Code project is to develop comprehensive testing suites designed for the printing protocols used in OpenPrinting projects (e.g., IPP). Specifically, the suites encompass: (1) unit tests and differential tests for IPP, detailing test inputs and expected outputs within the appropriate printing contexts, and (2) fuzzing enhanced by a custom validator to verify the correctness of outputs against the specifications. These suites will incorporate unified testing drivers and oracles (validated test input and output pairs) to ensure accurate and reliable results.
Contributors are expected to achieve:
The outputs of this project will not only serve as a valuable reference for generalizing testing across all OpenPrinting projects but also the documented progress can also lead to potential academic contributions, such as technical reports or research papers.
Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Jiongchi Yu, PhD Candidate at Singapore Management University (jiongchiyu at gmail dot com), George-Andrei Iosif, Security Engineer at Snap Inc. (hi at iosifache dot me).
Desired knowledge: C/C++, security/testing
Code License: Apache 2.0, MIT (licenses of the OpenPrinting projects)
Security-related project
1 contributor full-size (350 hours), Level of difficulty: Intermediate
OpenPrinting projects play a critical role in the printing infrastructure of countless systems, making their security paramount. Inspired by security auditing reports from other open source communities (CNCF: Security Audit for Karmada, Security Audit for Kubernetes and Security Audit for OpenSSF), we believe a comprehensive security auditing report could significantly enhance the robustness and reliability of these projects. This initiative will leverage advanced software analysis methods to conduct thorough security audits.
The audit process includes scoring OpenPrinting projects using OpenSSF’s Security Scorecard and examining the projects and their dependencies with respect to testing status, which encompasses adherence to continuous integration (CI) test best practices and test coverage assessments. Furthermore, dynamic testing should also be considered, for example, end-to-end fuzzing techniques such as AFLplusplus, which assists in the successful detection of CVE-2024-47076. Static analysis tools including cppcheck and flawfinder, Valgrind can be employed for checking the implementation flaws. The overall security audit should include dynamic software analysis methodologies to cover more extensive aspects of OpenPrinting projects.
Project Goals for GSoC 2025: The primary objective of this Google Summer of Code project is to complete a systematic security audit report for OpenPrinting. This comprehensive process includes maximizing the scores provided by the OpenSSF Security Scorecard and scanning dependencies using existing SADT tools. In addition to static analysis, incorporating dynamic testing methodologies will provide an exhaustive overview of security across the entire network of projects. The project aims to identify and mitigate potential vulnerabilities effectively, ensuring that a robust defense mechanism is in place to protect the integrity of the OpenPrinting infrastructure.
Contributors are expected to: Use or implement dynamic testing/auditing tools for analyzing OpenPrinting projects, which includes examining OpenSSF Scorecard of OpenPrinting projects and preparing detailed security auditing reports outlining discovered vulnerabilities. The contributor should also coordinate with security experts to address these issues effectively.
Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Jiongchi Yu, PhD Candidate at Singapore Management University (jiongchiyu at gmail dot com), George-Andrei Iosif, Security Engineer at Snap Inc. (hi at iosifache dot me).
Desired knowledge: C/C++, code auditing
Code License: Apache 2.0, MIT (licenses of the OpenPrinting projects)
1-3 contributors full-size (350 hours), Level of difficulty: Hard
Although driverless printing and scanning are governed by standards and specifications, real hardware implementations often have unique details that can deviate from these specifications, impacting the accuracy of our printing and scanning implementations.
We currently have the “ippeveprinter” tool, which implements an “abstract” IPP 2.x printer. However, we lack a behavior-accurate simulation of real printers and do not have any simulation for eSCL/WSD scanners.
The goal is to create a behavior-accurate simulator for multi-function printers (MFPs) that supports at least IPP 2.x for printing, eSCL and WSD for scanning, and DNS-SD and WS-Discovery for device discovery. We aim to build a growing collection of models representing various specific devices.
This simulator will consist of a core simulation engine that provides reference implementations of the aforementioned protocols, along with a customization engine that allows for the expression of implementation details specific to individual devices without the need to reimplement common functionalities repeatedly.
One of our key objectives is to make the process of creating MFP models semi-automated. For instance, printer attributes and scanner capabilities can be automatically obtained, while accurately simulating behavioral features may require manual testing and analysis to identify these details, along with scripting to express them in the simulator. We anticipate that actual device behavior will not deviate significantly from the “ideal” model implemented by the simulation core, allowing models to remain relatively straightforward. Ideally, the model creation process should be simple enough for mid-level technical personnel and qualified users to undertake independently.
This initiative opens up several new avenues:
Initially, our collection of models will be small and may contain inaccuracies. However, as we expand our model collection, we will be able to automatically detect most regression cases during the development of the entire printing and scanning stack.
The implementation of the simulation core has already started, what we need from the contributor(s) is to develop the initial collection of the printer models. During this phase, we will evaluate and refine the overall concept, establishing and assessing the methodology for creating MFP models.
Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD
Desired knowledge: Familiarity with relevant protocols (IPP, eSCL, WSD, DNS-SD), knowledge of the Linux printing and scanning stack, programming in C, and proficiency in Python or JavaScript (for scripting MFP models).
Code License: Apache 2.0, MIT (licenses of the OpenPrinting projects)
1 contributor full-size (350 hours), Level of difficulty: Hard
We do a lot of testing for quality assurance and security of our software, especially also tests of the data processing when printing and scanning. For now our only criteria to consider a test failed is a processing error, a crash, an infinite loop, or the output being empty. We do not verify whether the content of the output is actually what we have expected.
Evaluating the correctness of the content of the output is not easy, as we cannot compare it pixel by pixel, we rather need to determine whether a human being would see the content which they have sent to the printer. This means to recognize text, structures, colors, but with a certain tolerance.
There is free software work at GNOME for the CI testing of their GUI, which requires to analyse graphical screen content to evaluate whether the response of GUI apps to given user input is as expected, and this should be fully automated. This is the openQA project.
To compare graphical content they use the free software computer vision library OpenCV and also the universal file comparison tool diffoscope is used to check output.
With this we could for example take a PDF file, rasterize it in high quality, then “print” it/send it through a filter chain and afterwards compare the images. We can also OCR raster output to check whether the complete text of the input (plain text or PDF file) is conserved in the output, not having anything cut off at the borders and no glyphs missing or replaced by squares/placeholders for missing glyphs.
See also my report from the GUADEC 2024, the section “Workshop: openQA testing for your GNOME app, module or service”.
Tests which benefit from this are not only our CI testing in libcupsfilters, but also 2 of our other projects on this list:
Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD
Desired knowledge: C, Go, image processing and evaluation, computer vision, OCR
Code License: Apache 2.0, MIT (licenses of the OpenPrinting projects)
Probably many of you have already thought about that one can take an SBC, install Linux and CUPS or a Printer Application on it, and connect this to an old printer which is still mechanically perfect but needs a driver which is not available any more for some operating systems. Suddenly the printer turns into a modern, driverless IPP printer which can be used with any operating system.
But it is a little awkward having a little box dangling behind the printer which also occupies a power outlet. Also one can perhaps also make use of much cheaper SBC.
Imagine you could buy a tiny board for a few dollars and put it somewhere inside the printer and grab its power from the printer's power supply.
Such tiny boards are often not powerful enough to run Linux, but there is also the much more lightweight Zephyr operating system. This is a system for IoT applications on low-footprint hardware.
And this scenario does not only serve for cheap DIY solutions to save old printers, it also can be a base for cost-effective printer firmware development.
This project is about investigating whether one could run the components of the free software printing stack, as CUPS, PAPPL, libcupsfilters, … under the Zephyr operating system, and actually let this tiny print server execute printer drivers and print on legacy printers. Also the handling of print data and the need of resources here needs to be investigated. Can we hold several pages? Can we use Ghostscript? Or do we have to stream raster print data from the client to the printer?
Most desirable is to do this with PAPPL (Printer APPlication Library), as it is designed to emulate a driverless IPP printer in software, including the so-called “Gadget” mode to appear as an IPP-over-USB device when connecting the power supply USB port of the SBC with the client computer's USB.
Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Zephyr developers TBD
Desired knowledge: C, Zephyr, USB, network
Code License: Apache 2.0, MIT (licenses of the OpenPrinting projects)
1 contributor full-size (350 hours), Level of difficulty: Hard
Most software with print functionality or print administration functionality uses the CUPS library (libcups, 2.x, 3.x) to communicate with CUPS. This is easy when the software is written in C or C++ as the library is written in C. If the software is written in other languages, we need some connection between the library and the client code, the so-called bindings.
A programming language which gets more and more used nowadays is Rust, due to its memory-safety, eliminating the number-one source of crashes and vulnerabilities. Unfortunately, we do not have Rust bindings for libcups. And getting them is subject of this project.
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 medium-size (175 hours), Level of difficulty: Intermediate
It often happens that a print job, sent to a network printer or to a remote CUPS queue does not get printed and a "cups-pki-invalid" error will get logged. This is due to the fact that the locally saved certificate does not match the printer (any more).
To prevent man-in-the-middle attacks between a client and a network IPP printer with encrypted connection, the first time when a new network printer is accessed, the printer's certificate is loaded from the printer and saved locally. On subsequent accesses the printer's certificate is compared to the locally saved one and on mismatch the error is logged and the printing does not happen.
often this happens without an attack, just on a change of the printer configuration or a printer firmware update. Then the user screams on internet platforms, when they are lucky finds information about this problem and how to remove the old certificate to make the CUPS replace it by the current one and the printer print again.
To solve this nasty problem, we came to the conclusion to pop up a dialog which allows to remove the certificate file ("Reset certificte") by clicking a button..
The contributor's task here is to create such a dialog and make it pop up in the right situation. The pop-up should also be used for other common error scenarios which could be solved by a simple dialog.
The communication between the pop-up and CUPS should be done by the Common Print Dialog Backends (CPDB), extending the D-Bus interface and implementing the error handling in the CPDB CUPS backend.
Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Gaurav Guleria (gaurav dot gen3 at gmail dot com), Kushagra Sharma (b20251 at students dot iitmandi dot ac dot in), 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
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 medium-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