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.
Comments
19 responses to “Some benefits of printerd”
ALSA + dmix worked fine.
SysV init worked fine.
CUPS worked fine.
GNOME is a disease.
Please please please integrate a method for passing additional data to the “printer”… Things like requiring a phone number for a “fax” printer, so that I can send a fax for any application. Another might be requiring an email address for a print via email type printer… I am sure there are more, which would push for the idea of a generic system of handling backend specific parameters, and marking certain parameters as mandatory.
Nice article. I find this project really promising over the old CUPS.
So what you’re saying is..
DONT LIKE WHAT I DONT LIKE ?
@Dave: you’ve forgotten: ifconfig worked fine. But don’t be so sad, you surely can still download a distribution made in 1999, for your pleasure.
*yawn*
Pulse Audio works really well.
Systemd and upstart work fine, and are a lot quicker than sysvinit.
As for printing, it could sure need an improvement, regardless if that happens in CUPS or a new printerd.
@Dave:
yes and many thought that MS-DOS worked just fine as well…
Thanks for explaining the motivation behind this… I look forward to things developing!
PDF-only is a showstopper.
There are non-document printers out there. Label printers, receipt printers, etc. These don’t accept PDF (or PS or PCL.) They are very common in warehouses and retail.
Either printerd must accept those inputs, or it must co-exist with another print service, possibly on the same device.
No, PDF is required format for submitting print jobs to printerd, but printerd will send jobs to printers in whatever format they require by running filters just like CUPS does.
2 Wishes for a new printing system:
Easy, effortless setup for accounting (counting printed pages per user, per host etc.)
and:
Easily configured font for text filters. There is really no excuse for getting
printouts in Courier if you send text files, when there are pretty monospace
fonts included in modern Linux.
There will be no text filters. Jobs must be submitted as PDF.
Cups doesn’t. Not for those. Raw or plain text.
(some) receipt printers slow down a lot when printing non-text, and you can’t have stores or warehouses take minutes to print when it used to take seconds. I haven’t successfully used pdf2text for this, although in theory that’s possible.
Label printers take custom layouts. pdf2text wouldn’t work.
Oh, sorry, I see what you mean now. Yes, for circumstances like that it would probably have to just relay the raw job file. The point is that it won’t convert random things like images or text to PDF first.
Yeah, even though Cups does support this using custom options, it would be nicer to ask for the data in a more prominent way.
But maybe that is really just a printer dialog implementation problem, to eg. show the option on the first tab, like the output options for “Print to File”.
I actually hacked a cups filter at some point which would pop up a dialog via DBus. In this case it was to ask for a username/password (accounting on the printer) but a scheme like that could be used for any other purpose.
Nice job on your project – hopefully this will (ful)fill several important niches:
– an upgrade from p910nd
– something more suitable for space-constrained situations (like NAND images that have to fit in 32MB of space!) in embedded platforms
– something that will be able to mesh/play nicely with both iOS AirPrint and GooglePrint
Is this anywhere near a state where it could work w/ AirPrint?
(roughly speaking : CUPS + ppds + Avahi + a-few-other-goodies-n-tweaks = Linux_based_AirPrint Server
thanks,
Dave
Not yet: have to get local job printing working first.
How has printerd come along over the course of the last year? It does indeed sound promising, but I haven’t heard any news since the original announcement and this update.
It’s been stalled due to lack of time. 🙁