Recently I talked about a new print spooler under development, printerd. In that post I mentioned briefly how printerd is structured, but did not go very deeply into why or what the project is for.

Firstly, printerd is experimental and is very far from being a functional print spooler. It doesn’t yet run any filters, for instance, and has no backends of its own to transport jobs to devices. So far it is just a test of what a Linux print spooler would look like if it were written today.

There are several problems printerd aims to solve. Some of the solutions come automatically from implementing it as a polkit-enabled D-Bus system service. I mentioned one of them in the original post about printer: the fact of having an asynchronous client API. All D-Bus services can be used asynchronously thanks to the D-Bus client library. This approach means the print dialog will be able to use printerd without blocking (and without having to start another thread to use it).

Another benefit is the fact that security/authentication can be made much cleaner and more well integrated into a desktop system if polkit is the basis for policy decisions. Although there is some support for adding polkit support to CUPS in the shape of cups-pk-helper, the way this works is to effectively bypass the standard CUPS policy mechanism. In order to completely limit some operation from users, two different policies must be changed: the built-in CUPS policy in cupsd.conf, and the polkit policy for cups-pk-helper.

In contrast, printerd’s only interface is D-Bus and it uses polkit to authenticate operations. If extra security policy is added in future that cannot be expressed using polkit (for instance, printer-specific policy rules like CUPS has), that extra policy layer will be in addition to polkit, not an alternative. Currently, for example, cancelling a job requires that the user is permitted to use the org.freedesktop.printerd.job-cancel action (a polkit check), as well as being the user that submitted the job in the first place (an additional check). Both requirements must be fulfilled.

One more benefit of printerd is the idea of splitting the IPP server out from the local spooler. Currently printerd only spools files and does not provide IPP services but the idea is that when it does, this will be implemented out-of-process by a program that acts as a client to printerd. It will use printerd’s D-Bus interface, just like any other client. That way, users that want to print to local printers but are not interested in sharing those printers on the network don’t even have to run the IPP server. In fact, as printerd is an activatable system service, the spooler itself won’t even be running unless there is something for it to do.

By accepting only one format for printing, some complexity can be removed from the spooler. Generally people print from applications that generate PDF for printing. By using PDF as the required format, the task of selecting pages and arranging several pages onto each side (i.e. number-up) is hopefully made a little easier, as the structure of PDF makes this task more straightforward than PostScript does. Increasingly printers are able to understand PDF natively themselves. This means converting between formats can be kept to a minimum.

Finally, printerd is experimental, so ideas can be tested and developed. For example, I hope to get printerd to improve the latency between cancelling a job and having the printer stop feeding paper, by splitting the backend out of the filter pipeline, killing its input, and telling it to discard its send buffer. Another idea related to separating the filter pipeline from the backend is to begin filtering the next job before the backend finishes clearing out the last of its send buffer. I’m sure there are other areas for improvement that can be played around with in a project like printerd.