This page contains the details of a technical writing project accepted for Google Season of Docs.
Project summary
- Open source organization:
- The Linux Foundation
- Technical writer:
- PIYUSHgoyal16
- Project name:
- Tutorial and Design Guidelines for Printer/Scanner drivers in Printer Applications
- Project length:
- Standard length (3 months)
Project description
Overview
Classic printer drivers consisting of printer-specific filters and PPD (Postscript Printer Description, describes printer capabilities and which filters to call) files which have to be dropped in certain directories of the file system are replaced by so-called Printer Applications, emulation of an IPP network printer.
Most modern general-purpose printers are IPP printers that allow driverless printing. They advertise themselves via DNS-SD, clients can poll the capability information of them via IPP requests, and they use standard data formats for print jobs. Printers not providing this functionality, usually legacy or specialty printers need a printer driver.
A Printer Application is a daemon that detects the supported printers and advertises those printers on the localhost as an IPP Everywhere printer. Printer Applications contains the software to print incoming jobs on the printer(s) it supports, converting the data to the printer's native language, and it provides the info about the printer's capabilities to clients on request. The Printer Application even has a web administration interface, like an actual network printer.
As we know, Linux is moving to sandboxed packaging (Snap for example) and printing is also moving in that direction. In a sandboxed package, we cannot modify directory contents once it is built. Our system is no more modular. We cannot choose which printer driver package to install. Printer Applications address this problem of modularity and give us the same freedom as in the case of printer drivers.
Printer and scanner drivers in Snaps are not only a requirement for a snapped CUPS and snapped application, they work also on completely classic systems, but in contrast to classically packaged drivers they are OS-distribution-independent. You make a printer driver Snap and it works on all OS distributions which run snapd, no need to package printer drivers for each and every distribution (and version of them) independently and run into dependency hell. The other advantage is that the ancient concept of PPD files coming from PostScript printers is discontinued. In addition, by coupling the CUPS system and the printer driver by an IP connection instead of dropping files into the CUPS system, both the CUPS system and the Printer Application can be in separate sandboxed packages.
My task will be to describe how to design the drivers for printers and scanners for this form of packaging and how to package them into Snaps. The intention is to help anyone who writes printer or scanner drivers, especially also the hardware manufacturers, in the future to do it the right way.
The workflow of Printer Application can be summarised with the given flowchart:
The base for creating such Printer/Scanner Applications is PAPPL, a library providing most functionality for this, but also cups-filters containing code to be used for Printer Applications. The concept is still under development, mainly in this year's Google Summer of Code, but on September 14, when the documentation writing period starts, the coding period of GSoC has already ended and this is when OpenPrinting needs the tutorial.
Template for Printer Drivers Define Structure for JOB Data
Declare Constants Array for Media Sizes
Declare functions i) Callback or init A boolean function accepting driver name, driver data, etc and sets driver attributes correspondingly. If the details provided are appropriate it returns true and false on failure.
ii) print Boolean function accepting job, options for the job and the device. It prints a file and returns true on success and false on failure.
iii) rendjob Boolean function accepting job, options for the job and the device. It ends the job and returns true on success and false on failure.
iv) rendpage Boolean function accepting job, options for the job, device and the page number. It ends the page and returns true on success and false on failure.
v) rstartjob Boolean function accepting job, options for the job and the device. It starts the job and returns true on success and false on failure.
vi) rstartpage Boolean function accepting job, options for the job, device and the page number. It starts the page and returns true on success and false on failure.
vii) rwrite Boolean function accepting job, options for the job, device, line number and the character array. It writes the line and returns true on success and false on failure. viii) optional functions such as identify (helps in identification of printers based on the action provided), compress(Compress a line of graphics), etc