This is an old revision of the document!
Google Summer of Code 2022: OpenPrinting projects
Organization Administrators
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).
Introduction
Printer Drivers get Printer Applications
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:
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 (
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 ~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.
IPP Scan and Scanner Applications
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 appication, 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, preferrably 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.
What we are currently doing at OpenPrinting
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
-
PAPPL - Printer Application Framework - Library for Printer/Scanner Applications
pappl-retrofit - PPD/Classic CUPS driver retro-fit Printer Application Library
-
-
-
-
-
sane-airscan - The “airscan” SANE backend, supports driverless eSCL and WSD scanning, IPP Scan support is planned
-
See also
Project Ideas
+ Still needs to get updated!! +++**
=====GUI for listing and managing available IPP Print/Scan services (or DNS-SD-advertised network services in general)=====
As described above, all available printers and scanners will simply be IPP services (physical network printers or Printer Applications) and drivers will be Printer Applications. They are managed by their web administration interfaces and/or IPP System Service. Local CUPS queues are simply automatically popping up for each IPP print service available.
Due to this we do not need any more the classic printer management tools where the local CUPS queues are listed and you modify their properties. Instead, your printer/scanner management tool should list all IPP services, native hardware devices, Printer Applications, shared CUPS queues on remote servers. For each service (1 service = 1 host:port) a main entry with sub-entries for each printer, scanner, or fax out facility. These entries should have action buttons, for main entries to open the web interface in a browser, pop up an IPP System Service status/control window, ... and for sub-entries buttons to go to the web interface page of this printer, pause/resume/set-as-default quick-access buttons, ...
This way the user knows which IPP services are available and can easily click to their management interfaces (many users do not know about web interfaces for network services or how to find them). Especially if he installs a Printer Application from the Snap Store he needs to know how to set up his printer with it.
All the information needed to create the list is provided by DNS-SD (Avahi). DNS-SD advertises all printers, scanners, web interfaces, IPP System Service interfaces, ... see the output of "avahi-discover" and "avahi-browse".
And with this one is already close to having a general network service management tool, also listing the DNS-SD services which are not related to printing with buttons to their web interfaces (imagine the user can open the web interface of his router with a simple mouse click). This would be the "user-friendly" avahi-discover then, showing the services in a user-friendly order an presentation.
The student'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+
=====GUI to guide the user to the correct Printer Application=====
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, themany 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 to find Printer Applications which are not installed on the local system.
The student'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+
=====Converting classic CUPS printer drivers into Printer Applications (multiple students)=====
To replace classic Linux distributions based on RPM or DEB packages by completely sandboxed/all-Snap distributions it is also needed to assure that hardware which worked before will still work in the new distribution.
For this we want to retro-fit all printer drivers into Printer Applications and make these available as Snaps in the Snap store. This way for all printers which worked under Linux before, there is a driver in the Snap Store, so all distributions which support Snap packages (have snapd installed) will support all these legacy printers without needing to take the responsibility by themselves.
Together with the CUPS Snap we can have all-Snap distribution with the same printing coverage as conventional distributions.
The retro-fit should not be very complex, as we have the Printer Application library PAPPL and a printer driver retro-fit library (will be available before coding starts) containing most of the code of the PostScript Printer Application at hand. The intention is to retro-fit all common printer driver projects using these tools and avoiding to modify the original driver's code, as we do not have the printer hardware for testing and in most cases the original driver code is not maintained any more.
Driver projects are (derived from "apt search printer-driver-" on Ubuntu Hirsute):
* Foomatic/Ghostscript built-in
* "brlaser": (Some) Brother laser printers
* "c2050": Lexmark 2050 Color Jetprinter
* "c2esp": Kodak ESP AiO color inkjet Series
* "cjet": Canon LBP laser printers
* "dymo": DYMO label printers
* "escpr": Epson Inkjet that use ESC/P-R
* "foo2zjs": ZjStream-based printers
* "fujixerox": Fuji Xerox printers
* HPLIP: HP printers and multi-function devices
* "m2300w": Minolta magicolor 2300W/2400W color laser printers
* "min12xxw": KonicaMinolta PagePro 1[234]xxW
* "oki": OKI Data printers
* "pnm2ppa": HP-GDI printers
* "ptouch": Brother P-touch label printers
* "pxljr": HP Color LaserJet 35xx/36xx
* "sag-gdi": Ricoh Aficio SP 1000s/SP 1100s
* "splix": Samsung and Xerox SPL2 and SPLc laser printers
The student's task here is to retro-fit one or more driver projects, so that these new Printer Applications can be put into the Snap Store.
In some cases there are also some special tasks:
* "foo2zjs" should be able to let the user download/add firmware files and color profiles and make the firmware files be loaded into the printer everytime when it is turned on.
* Foomatic needs to support options of string or numeric style, which in the original are implemented with PPD extensions.
* HPLIP retro-fit: HP should not maintain such a retro-fit as-is, they should go native, but this can be of help for them and also of help for users until HP switches over. Especially it should NOT be put into the Snap Store under the HPLIP name
* Closed-source drivers (not in the example list) could need to run the filters in a chroot as they can have hard-coded directory paths
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), Smith Kennedy, HP (smith kennedy at hp dot com), Dheeraj Yadav (dhirajyadav135 at gmail dot com), TBD
Desired knowledge: %%C/C++%%, CUPS
Code License: Apache 2.0
=====Firmware and other file handling in PAPPL=====
For some printers there are firmware files, either as an upgrade or if the printer is a cheaper model which does not have non-volatile memory to hold the printer's firmware, requiring the firmware be loaded from the computer each time the printer is turned on. Other printers could be enhanced with fonts or custom color profiles.
This can easily be handled by the Printer Application, offering an appropriate page in its administration web interface where the user can upload files into Printer Application's file space and the Printer Application would apply them somehow, as loading them into the printer as update or enhancement, loading them into the printer everytime when the printer is turned on, use them in the job filtering process, ...
An example already exists, in the [[https://github.com/OpenPrinting/ps-printer-app/ PostScript Printer Application]] the facility to upload custom PPD files to support additional printer models, see the “Add PPD files” page in its web interface.
The student's task here is to generalize this feature, add common functions, like multiple, arbitrary file upload, managing and removing already uploaded files, callback function support for applying the files, for example that the developer of a Printer Application can implement the code for the proprietary firmware upload method in a callback, …
As an example application the student could retro-fit the “foo2zjs” printer driver into a Printer Application, as this driver supports appropriate printers and handles the types of files mentioned here.
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), TBD
Desired knowledge: C/C++, CUPS
Code License: Apache 2.0
=====Converting SANE scanner drivers to Scanner Applications=====
By the time when coding starts we will have implemented IPP Scan server functionality to PAPPL and with this we have the base for creating Scanner Applications. To support the thousands of scanners which are already working with SANE with the new IPP Scan/Scanner Application method, we need to create a retro-fit Scanner Application which uses SANE internally.
One could theoretically make use of the fact that most SANE backends are open-source and so extract the knowledge about how the scanners work and write native drivers, but without having all these scanners at hand for testing the risk is too high, as mentioned above here for the retro-fitting of printer drivers.
Therefore we want to create a framework to encapsulate existing SANE backends in a Scanner Application and do not modify the code of the backends themselves. This would be a SANE fromtend, but not as the ones we know which are primarily operated by a GUI or by the command line. Instead, it will be operated by IPP Scan and an administration web interface, all with the help of PAPPL.
The student's task is to create this SANE retro-fit framework, especially making one Scanner Application from the sane-backends projects, but also allow to retro-fit any other SANE backend from a separate project (like HPLIP) into a Scanner Application.
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
=====cups-filters: Move rastertopwg from CUPS into a filter function=====
To print on driverless IPP printers following the AirPrint and/or IPP Everywhere standard CUPS got the rastertopwg filter which converts CUPS Raster into PWG Raster and Apple Raster.
With the move from filters as individual executables to filters as library functions we also want to convert this filter into a filter function in libcupsfilters, allowing the use in Printer Applications and especially also for replacing the CUPS filter chain by a single, universal filter.
The student's task is to take the code of the rastertopwg filter in CUPS into libcupsfilters, and convert it into a filter function, a function with standardized interfaces for input, output, logging, printer capabilities, job attributes, …
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
=====cups-filters: Create a single, universal CUPS filter to replace the chain of individual filters=====
To convert the job data format from the input data type to what the printer needs CUPS calls a sequence of different individual filters, usually one filter to convert the incoming format into PDF (if needed), then the pdftopdf filter to flatten filled PDF forms and to apply page management options (N-up, selected pages, scaling, …), and after that one or more filters to get the data into the printer's native PDL.
This makes CUPS call a lot of external executables, which is resource-consuming. Therefore in this project we want to create a universal CUPS filter which causes filter functions in the libcupsfilters library in an appropriate order to replace the work of the current, individual CUPS filters.
It should check what the inout format and what the needed output format is and by this select the input filter to get PDF and the output filters to turn PDF into the desired output format, and then it should call the sequence of filter functions.
In addition, small improvements on the filter function mechanism could be made, too.
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
=====cups-filters: Convert filters to filter functions (multiple students)=====
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. Also for Scanner Applications filters are needd, so that the user can choose the file format he wants.
Most filtes are already converted, but some are still missing. These are especially:
* pdftoraster, mupdftoraster: Turn PDF into CUPS/PWG Raster with alternative tools/libraries
* texttopdf: Input filter for plain text files
* bannertopdf: Filter to generate banner pages and a printer test page
This task can be devided up for more than one student.
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
=====cups-filters: Make sure all filter functions work without PPD files=====
As already described in the introduction we want to get rid of PPD files in the printing process and control jobs by IPP attributes.
For this all filter functions also need to work correctly if there is no PPD file assigned to the print queue. They should as well understand standard IPP attributes as their options and printer IPP attributes for default settings.
The filter function concept already provides the needed interfaces, but the code of each filter function needs to be checked to see whether the filter actually correctly works without a PPD file.
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
=====cups-filters: In filter functions call Ghostscript via libgs and not as external executable=====
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 student'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
=====cups-filters: Add Avahi calls for discovering and resolving driverless IPP printers to API and optimize the processes=====
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 student'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
=====cups-filters: Create OCR filter to deliver scans as searchable PDFs=====
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 student'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
=====Turn the scp-dbus-service methods - GetBestDrivers and MissingExecutables - of system-config-printer into C=====
system-config-printer was the default printer setup tool in Red Hat/Fedora Linux for a lot of time and also got adopted by Ubuntu around ten years ago. During this time it received a lot of development work, especially on the algorithms for finding the best driver for a printer and for identifying whether printer discovery results from the CUPS backends actually come from the same physical printer.
To make these algorithms available for other printer setup tools (both interactive GUI tools and programs which fully automatically create print queues without user interaction) they got moved into a D-Bus service, scp-dbus-service. Now every other program can simply call the needed function via a D-Bus API. The printer setup tool in the GNOME Control Center for example works this way.
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 student'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
