Classic printer drivers for CUPS-based printing environment consist of print filters which convert a known page data format (like CUPS/PWG Raster, PostScript, PDF, …) into the printer's native data format and PPD (PostScript Printer Description) files which describe the printer's capabilities, user-settable options, and the way how the print filters are used.
The PPD files and print filters have to be put into standardized directories of the installed CUPS system so that CUPS finds them and allows the selection of this printer driver when setting up a printer (or selects the driver automatically when identifying a printer as supported).
This method works well in standard desktop and server systems using RPM or Debian packages and when the source code of the driver's filters is available or the driver is packaged for the operating system distribution in use. If the CUPS environment is provided in a sandboxed package like this Snap adding files to the CUPS installation is not possible, and in addition, one wants to provide the drivers in distribution-independent binary packages, as for example Snaps. Also the CUPS project is deprecating the use of PPD files.
The solution, suggested by Michael Sweet, the author of CUPS, are Printer Applications. Printer Applications are simple daemons which emulate a driverless IPP network printer on localhost, do the conversion of the print jobs into the printer's format, and send the job off to the printer. And as a physical driverless IPP printer they advertise themselves via DNS-SD and provide there capability information on (IPP) request from the client.
The IP connection between CUPS and the Printer Application allows both being in different sandboxes (for example being installed from different Snap packages) and the printer setup is completely automatic. When the Printer Application's daemon is running and the printer is connected and turned on, the daemon discovers the printer and automatically advertises it on the local machine via DNS-SD. Then CUPS discovers the printer and automatically sets up a print queue with an auto-generated PPD file.
The student's tasks here are
- Create a universal printer application framework which can be packaged with print filters and PPDs to make up a Printer Application
- Use this framework to create Printer Applications for drivers like HPLIP, foo2zjs, Gutenprint, SpliX, …
- Use this framework to make a Printer Application for Foomatic
- Making Snaps of Printer Applications.
The tasks can be distributed to more than one student if needed.
Till Kamppeter, Project Leader OpenPrinting (till at linux dot com), TBD
C programming, DNS-SD, IPP
Apache 2.0, MIT