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 Libera.Chat
Our code repositories: OpenPrinting GitHub
Keep in touch with OpenPrinting's state of the art.
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).
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 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 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 ~2 years 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), but IPP Scan also helps 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 the IPP Scan standard. 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 IPP Scan. 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.
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
1 contributor full-size (350 hours).
Modern printers usually are driverless IPP printers, and those get discovered and set up fully automatically with CUPS, no Printer Application is required for them, so it is easy for users to get up and running with them.
Printers which do not do driverless IPP are either legacy printers, the many older printers which got developed before driverless IPP printing existed, and specialty printers. These need Printer Applications. As there will be several different Printer Applications and each one supporting another set of printers it is not trivial for the user to discover available non-IPP-driverless printers and find out which is the Printer Application to use and whether it is already installed.
So we need some guide for the user. The idea is a GUI tool which lists available, non-IPP-driverless printers, local (USB) and network devices. If the user selects one of them, all installed Printer Applications which support this printer are shown, and for each a button to open the Printer Application's web interface and also a quick auto-add-this-printer button. In addition to the list of suitable Printer Applications there should also be a button which does a fuzzy search for the printer make and model on the Snap Store/the OpenPrinting web site to find Printer Applications which are not installed on the local system. There is already a concept to implement an appropriate search index on OpenPrinting which will be used by this GUI.
The contributor's task is to implement such a tool in GTK, ideally as a module for the GNOME Control Center.
Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), GNOME/GTK developers, TBD
Desired knowledge: C/C++, GTK, DNS-SD/Avahi, CUPS/IPP
Code License: GPL-2+ and LGPL-2+
1 contributor full-size (350 hours).
In the Google Summer of Code 2021, Bhavna Kosta has started the work on Scanning support in PAPPL so that PAPPL not only can be used for creating Printer Applications (emulation of a driverless IPP printer) but also for creating Scanner Applications (emulation of a driverless IPP/eSCL scanner), or even an emulation of a driverless IPP multi-function device.
She has created the needed data structures and API functions needed to extend PAPPL for supporting scanners.
Next steps to complete the support are the following:
The contributor's task to implement the above-mentioned components to complete the framework needed by all Scanner Application. With this done, only code for the particular group of scanners to support (scanner driver) needs to be added to PAPPL.
Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Michael Sweet, author of CUPS and PAPPL (msweet at msweet dot org), Jai Luthra (luthrajaiji at gmail dot com), Dheeraj Yadav (dhirajyadav135 at gmail dot com), Alexander Pevzner (pzz at apevzner dot com), TBD
Desired knowledge: C/C++, CUPS
Code License: Apache 2.0
1 contributors full-size (350 hours).
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 Chrome.
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 22 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.
As far as I know the GTK, Qt, and LibreOffice print dialogs support temporary print queues now (but only recently, there are many old dialog versions around), but now we are at the next challenge as we have to assure that the print dialogs use CUPS APIs which do not handle PPDs on the dialog side, so that if the system switched to PPD-less CUPS 3.x that the dialog continues to work. If we get the dialogs using CPDB, these changes happen (if actually needed) only in the CUPS CPDB backend, not in each print dialog individually.
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 GTK, Qt, (LibreOffice has already CPDB support AFAIR), Chrome, and perhaps others. Also important are backports, as there are many apps based on old toolkit versions around in the distributions (Firefox? Thunderbird?).
For the CPDB integration we do not need UI design work.
Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), GNOME/GTK developers, Qt developers, TBD
Desired knowledge: C/C++, GTK or Qt, DNS-SD/Avahi, CUPS/IPP
Code License: GPL-2+ and LGPL-2+, Apache 2.0
1 contributor full-size (350 hours).
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:
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).
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:
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 half-size (175 hrs)
cups-filters has always provided the filters which CUPS needs to convert job data from the input format (PDF in most cases) into the printer's native language. For use in Printer Applications the filters got converted from standalone executables to library functions, reducing the number of calls of separate executables and so saving resources.
The filter functions themselves also often call external executables, and this we can also try to avoid. For example the ghostscript() filter function calls Ghostscript and Ghostscript also has a library, libgs, which allows Ghostscript to be called as library function.
The contributor's task here is to convert the ghostscript() filter function to call Ghostscript via libgs. Here it is also important to make everything working in a multi-threading environment as Printer Applications can process jobs in parallel. Ghostscript has a special GS_THREADSAFE build mode for that.
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
1 contributor half-size (175 hrs)
The cups-browsed daemon and the “driverless” utility discover DNS-SD-advertised IPP printers in the network, for the former to automatically create queues and the latter to list the printers for printer setup tools and auto-generate PPD files for them.
DNS-SD/Avahi discovery goes in two steps: First there is the service discovery itself which is very fast, then each discovered service needs to get resolved to get the complete DNS-SD record, this is a rather slow process. A complete DNS-SD discovery run (only on IPP-relevant service types) including resolving all discovered services can take a long time, especially in large networks.
cups-browsed resolves each service which gets discovered, and many of them are duplicate, for example IPP and IPPS, IPv4 and IPv6, and several different network interfaces, as Ethernet, Wi-Fi, and imterfaces for virtual machines. Here one could sort and filter before resolving, for example start resolving only if the discovery run has completed, then resolve only the needed ones.
The “driverless” utility calls “ippfind” to do the DNS-SD discovery and resolving, here further optimization would be possible if the utility directly deals with Avahi and then saves unneeded resolving steps.
The contributor's task is here to add a convenience API for Avahi discovery and resolving calls to libcupsfilters. For example create library functions avahiResolveService(), avahiBrowseResolve(), avahiBrowseOnly() in new files cupsfilters/avahi.[ch], using code of cups/http-support.c and tools/ippfind.c from CUPS. In a next step these functions should be used in cups-browsed and in the “driverless” utility to optimize their performance.
Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), Sahil Arora (sahilarora dot 535 at gmail dot com), TBD
Desired knowledge: C/C++, CUPS
Code License: Apache 2.0
1 contributor half-size (175 hrs)
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), Alexander Pevzner (pzz at apevzner dot com), TBD
Desired knowledge: C/C++, CUPS
Code License: Apache 2.0
1 contributor full-size (350 hrs)
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.
GNOME Control Center uses two methods - GetBestDrivers and MissingExecutables - for its printer setup. The GetBestDrivers method is used for finding the right printer drivers from ones which are available on the system. The MissingExecutables method is checking method, which is run after finding the best driver and checks if any additional software is needed for getting the printer functional.
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. Also most printer setup tools are written in C, Therefore it makes sense to convert the D-Bus service into the C language.
The contributor's task is to turn the two mentioned methods of system-config-printer into C, first as a C library with API, then as a D-Bus service (would work out-of-the-box with many GUIs) if the C library will be finished. This will make it easier to use those methods in other print tools in practically any programming language.
Mentors: Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), system-config-printer upstream developer Zdenek Dohnal (zdohnal at redhat dot com)
Desired knowledge: C/C++ programming, Python programming, autoconf/automake(creating configure and Makefile), basic testing
Code license: GPL 2+ or MIT