printerd modularizes Linux printing

In May, Red Hat's Tim Waugh and Richard Hughes announced the printerd project; a new print spooler implemented as a D-Bus system service. Printerd is deemed experimental by its creators, but it offers a different approach from the CUPS-based Linux printing system that has dominated distributions for years.

CUPS, of course, includes a number of modules that connect together to form the life-cycle of a print job. There is the spooler, which schedules print jobs initiated by applications, followed by a series of filters that transform the data (including scaling, format changes, color-to-grayscale conversions, and N-up placement), plus back-end drivers for specific printers. Printerd is an effort to write a new scheduler from scratch — one that can be integrated directly with the system services of a modern Linux-based OS.

System services

At a basic level, that design decision means two things. First, the printerd spooler interacts with applications over D-Bus, and second, the spooler uses PolicyKit to enforce security. The CUPS API is based on the Internet Printing Protocol (IPP), which allows client applications to connect to the print server and request information (such as a list of available printers or their capabilities) or submit and check on print jobs. Policy, such as which users are allowed to access a printer, is spelled out in the cupsd.conf configuration file. It allows administrators to control access on the basis of function (such as sending printer jobs or canceling jobs), IP address, username, or group, and it covers general settings like authentication method.

Printerd's D-Bus API is modeled on IPP, but it is not intended to be an IPP implementation, and thus has some minor differences. Waugh said in the initial announcement that "the aim is to be able to implement an IPP server on top of the D-Bus API as a separate process." This separates the IPP server from the local print spooler, allowing computers with only un-shared, local printers to dispense with managing an IPP service. By using D-Bus, printerd also allows client applications to access the print spooler asynchronously, which is not possible with CUPS. This would be useful for shared printers, but also for programs that need to print automatically. As it is today, printing through CUPS either blocks the application or forces it to start a new thread.

PolicyKit integration does not offer different security features than CUPS's own security framework, but it does make it easier to deploy a system-wide policy across user accounts. As Waugh explains in a May 23 blog post, there is a CUPS plugin called cups-pk-helper that uses PolicyKit to enforce a security policy, but it works by bypassing the cupsd.conf settings altogether. Thus, to restrict access to a certain function (e.g., canceling all print jobs on a shared printer), one would need to specify the security rule in both CUPS and PolicyKit.

Print pipelines and the future

Another modernizing choice in printerd design is that it supports only PDF as its print job format. Waugh's rationale is that basing the workflow on PDF dramatically simplifies the job assembly process; PDF has support for selecting and arranging individual pages built in to the format itself (which is necessary, for example, in automatic duplex printing). The other main contender for a job format is PostScript, but although there are vendor-specific conventions for page-selection and layout manipulation, they are not consistently implemented.

Nevertheless, commenters on the blog took issue with Waugh's assertion that "generally people print from applications that generate PDF." While it might be true that most documents can be rendered to PDF for printing, not all can, and not all applications are designed to produce PDF. Plain text files, for example, are handled automatically by CUPS filters, and would require a special filter to be printed with printerd. Many specialized printers, such as those designed for printing labels or photos, need lower-level output formats than the standard file types embedded in a PDF, although in practice they tend to use special drivers (such as those maintained by the Gutenprint project) as well, so they are already exceptions to the standard pipeline.

In spite of the alarm expressed by some over printerd's PDF-only policy, it is important to remember that PDF print queues are already the plan settled upon by the vendor-neutral OpenPrinting workgroup at the Linux Foundation. GTK+ and Qt, the two most widely-used application toolkits, already support PDF printing pipelines, as do LibreOffice and Mozilla, two large projects which, together, arguably generate as much of the printed matter on a typical Linux desktop as the toolkits. Ubuntu formally became a PDF-pipeline distribution with the 11.10 release, and the IEEE's Printer Working Group seems poised to adopt PDF as its standard page format, too.

That said, it is interesting to note that when we last examined PDF print queues in March 2012, the issue at hand was that Apple, the corporate parent of CUPS, had begun making changes to the stack that adversely affected non-Apple systems. The changes in CUPS 1.6 introduced some additional work for Linux printing system maintainers, but the bigger fear was that those changes were just the tip of the iceberg, and that future releases would make CUPS less and less relevant to Linux. At that time, Waugh commented that a Linux-centric CUPS replacement had been discussed, but that it was not in the works "for the time being."

Waugh still describes printerd as "experimental" and cautions readers of his blog that it is an attempt to test and develop print pipeline ideas. Among his interests he lists several outstanding problems he would like to solve, including the lag time between canceling a print job and having the printer stop the paper feed, and separating the filter pipeline into a separate process from the driver backend, in order to better more efficiently multiplex multiple simultaneous print jobs.

Technically, applying a filter chain to a print job is a different part of the pipeline than the spooler, so that work would probably not be part of printerd itself. But it seems clear that Waugh is envisioning a post-CUPS printing landscape. Furthermore, regardless of how long it takes to arrive or whether or not printerd is ultimately part of the final product, he seems intent on splitting the individual steps in the print pipeline into separate tools. That is probably a good approach; today it is difficult to explain what CUPS is (at least succinctly) because it bundles so many discrete steps into a single, monolithic package. Modularizing the tools could make it simpler to maintain quality printer drivers, plus cleanly separate local and IPP printing. There is no telling if or when such a modular printing stack would prove preferable to CUPS, but for now printerd and related experiments may at least offer the opportunity to find out.