For the last few weeks I’ve been working on an experimental new print spooler called printerd. It was designed in collaboration with Richard Hughes and it aims to be a modern print spooler for Linux.
It is a polkit-enabled D-Bus system service, written using the GLib object system. Although modelled on concepts from IPP (Internet Printing Protocol), printerd is not in itself an IPP server. Its only interface is D-Bus, although the aim is to be able to implement an IPP server on top of the D-Bus API as a separate process. Having a D-Bus interface means that applications wanting to print automatically get to use printerd asynchronously.
As a design decision, the range of input formats accepted by printerd will be very limited: essentially only PDF. The existing CUPS drivers and backends will be compatible with printerd.
There isn’t much written yet aside from the basic framework and a very simple command line tool.
Feel free to take a look around: http://github.com/hughsie/printerd
$ pd-client -v print-files myprinter ~/Documents/portrait-a4.pdf TI:15:09:58 getting printerd manager TI:15:09:58 Getting printer /org/freedesktop/printerd/printer/myprinter TI:15:09:58 Job created: /org/freedesktop/printerd/job/1 TI:15:09:58 Document added TI:15:09:58 Job started Job path is /org/freedesktop/printerd/job/1 # printerd -v TI:15:02:46 Entering main event loop TI:15:02:46 add device usb://HP/DESKJET%20990C?serial=US05N1J00XLG [...] TI:15:02:46 Connected to the system bus TI:15:02:46 Acquired the name org.freedesktop.printerd on the system message bus TI:15:08:52 Handling GetDevices TI:15:08:57 Handling GetDevices TI:15:09:12 Checking authorization of :1.642 for org.freedesktop.printerd.printer-add TI:15:09:12 Authorized TI:15:09:12 Creating printer from device HEWLETT_PACKARD_DESKJET_990C_US05N1J00XLG TI:15:09:12 add printer myprinter TI:15:09:58 Checking authorization of :1.647 for org.freedesktop.printerd.job-add TI:15:09:58 Authorized TI:15:09:58 Creating job for printer myprinter TI:15:09:58 New job path is /org/freedesktop/printerd/job/1 TI:15:09:58 Created job path is /org/freedesktop/printerd/job/1 TI:15:09:58 [Job 1] Adding document TI:15:09:58 [Job 1] Got file descriptor: 10 TI:15:09:58 [Job 1] Starting job TI:15:09:58 [Job 1] Spooling TI:15:09:58 [Job 1] Created temporary file /tmp/printerd-spool-AHFWDW TI:15:09:58 [Job 1] Set job state to pending TI:15:09:58 Job 1 changed state: pending TI:15:09:58 Printer for job 1 idle so starting job TI:15:09:58 [Job 1] Starting to process job TI:15:09:58 [Job 1] Using device URI usb://HP/DESKJET%20990C?serial=US05N1J00XLG TI:15:09:58 [Job 1] Executing /usr/lib/cups/backend/usb TI:15:09:58 [Job 1] Env: DEVICE_URI=usb://HP/DESKJET%20990C?serial=US05N1J00XLG TI:15:09:58 [Job 1] Arg: usb://HP/DESKJET%20990C?serial=US05N1J00XLG TI:15:09:58 [Job 1] Arg: 1 TI:15:09:58 [Job 1] Arg: :1.647 TI:15:09:58 [Job 1] Arg: job 1 TI:15:09:58 [Job 1] Arg: 1 TI:15:09:58 [Job 1] Arg: TI:15:09:58 [Job 1] Read 1024 bytes from spool file TI:15:09:58 Job 1 changed state: processing TI:15:09:58 [Job 1] Wrote 1024 bytes to backend TI:15:09:58 [Job 1] Read 1024 bytes from spool file TI:15:09:58 [Job 1] Wrote 1024 bytes to backend TI:15:09:58 [Job 1] Read 1024 bytes from spool file TI:15:09:58 [Job 1] Wrote 1024 bytes to backend TI:15:09:58 [Job 1] Read 1024 bytes from spool file TI:15:09:58 [Job 1] Wrote 1024 bytes to backend TI:15:09:58 [Job 1] Read 1024 bytes from spool file TI:15:09:58 [Job 1] Wrote 1024 bytes to backend TI:15:09:58 [Job 1] Read 1024 bytes from spool file TI:15:09:58 [Job 1] Wrote 1024 bytes to backend TI:15:09:58 [Job 1] Read 1024 bytes from spool file TI:15:09:58 [Job 1] Wrote 1024 bytes to backend TI:15:09:58 [Job 1] Read 1024 bytes from spool file TI:15:09:58 [Job 1] Wrote 1024 bytes to backend TI:15:09:58 [Job 1] Read 564 bytes from spool file TI:15:09:58 [Job 1] Wrote 564 bytes to backend TI:15:09:58 [Job 1] Spool finished TI:15:09:58 [Job 1] backend: STATE: +connecting-to-device TI:15:09:58 [Job 1] backend: DEBUG: Printer using device file "/dev/usb/lp0"... TI:15:09:58 [Job 1] backend: STATE: -connecting-to-device TI:15:09:58 [Job 1] backend: DEBUG: backendRunLoop(print_fd=0, device_fd=3, snmp_fd=-1, addr=(nil), use_bc=1, side_cb=0x7f053adc6c30) TI:15:09:58 [Job 1] backend: DEBUG: Read 8192 bytes of print data...
UPDATE: Fixed URL as the project has moved to github.com.
Comments
23 responses to “Announcing printerd”
[…] Announcing printerd For the last few weeks I’ve been working on an experimental new print spooler called printerd. It was designed in collaboration with Richard Hughes and it aims to be a modern print spooler for Linux. […]
printerd has been added to the LinuxLinks.com directory.
Great! Looking forward!
This is exciting. I would love to remove CUPS from my life. Especially if you make sensible defaults for collated copies printed double-sided. If a document has three pages, for example, CUPS will place page 3 of one copy and page 1 of the next copy on the same sheet of paper.
Announcing printerd, another software we want to be used everywhere but were we did not contact anyone else than ourselves when writing it! Like colord, systemd et al.
Good job!
Regis: actually that situation is an application bug in every case I’ve seen. What happens is that the application thinks it has to do more work than it really does, and generates copies itself. This is always wrong.
What the applications should do is say “here is the document, please print 2 copies and duplex them.”. What e.g. evince actually does is say “here is a document, please duplex it” — when in fact the provided document is what you wanted to print, twice (e.g. pages 1, 2, 3, 1, 2, 3).
Albert: I think most people who have a stated interest in printing on Linux (e.g. printing maintainers in distributions, attendees at the OpenPrinting Summit etc) knew that printerd was coming already. As it stands, printerd is still at a very early stage of development and more help would definitely be welcome. Did you have a constructive suggestion to make?
What is the reason for printerd’s existence? What problems are you trying^H^H^H^H^H^Hgoing to solve?
It would be interesting to know what problem you are trying to solve.
Why “eventually only PDF”? Many printers support postscript directly, so iI do not understand why you need to double conversion ps -> pdf -> ps in this case.
Also pdf supports many auxilary features. like embedding JS, text forms or 3d graphics. Are you going to somehow restrict the set of valid extensions?
[…] и Ричард Хьюз (Richard Hughes), создатель проекта PackageKit, представили проект printerd, в рамках которого создан новый […]
What issues do you have with cups that can’t be dealt by extending cups?
The reasons for accepting only PDF are that PDF has a better model for shuffling pages around: each page is fully described separately from the others, unlike can often be the case in PostScript. This is important for printing only selected pages, or for putting several pages on a side (number-up). Applications generally produce PDF output for printing these days, so conversions from PostScript to PDF in the first place should be minimal.
There are several problems printerd aims to solve. Having an asynchronous client API is a start, and implementing the spooler as a D-Bus service does this as D-Bus automatically provides asynchronous client communications — this makes it easier to program UIs such as the print dialog in such a way that they do not block.
Another advantage printerd offers is a coherent security policy incorporating polkit. CUPS provides its own security policy mechanism, but the polkit mechanism is better suited to providing desktop integration. The way this is solved with CUPS is to provide an alternative security mechanism using polkit (cups-pk-helper), and this effectively bypasses the regular CUPS security policy. The result is that the two policy mechanisms are side by side, and if one prevents you doing what you want then you get to try the other.
In contrast, printerd’s only interface is D-Bus. 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) that extra policy layer will be in addition to polkit, not an alternative.
One more benefit of printerd is the idea of splitting the IPP server from the local spooler. Currently printerd only spools files and does not provide IPP services. The idea is that an IPP server can be implemented on top of printerd, using its D-Bus client API. That way, systems 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.
[…] « Announcing printerd […]
Thank you for the heads up about all of this. If there are plans to also develop the other components required for a comprehensive printing system, I’d ask that there be support for page quotas and accounting, and secure, authenticated printing (https).
Page accounting is one reason to require PDF input actually. Doing that for PostScript is a bit awkward.
Secure network printing is quite a long way off for printerd at the moment.
So, what about this: http://www-h.eng.cam.ac.uk/help/tpl/graphics/dsc.html ?
How do I here suggest a more experienced comrades, usually in the header of PS clearly shows the number of pages in the document.
> Doing that for PostScript is a bit awkward.
Actually, there is a Document Structuring Conventions or DSC for postscript.
http://en.wikipedia.org/wiki/Document_Structuring_Conventions designed specifically for this purpose.
Also there is no postscript printing system which generates “showpage” postscript command in a loop thus a page count for postscript document without DSC should be a quite dumb “showpage” command counting.
> The reasons for accepting only PDF are that PDF has a better model for shuffling pages around: each page is fully described separately from the others
Actually, no. A valid PDF document should have document wide embedded fonts if non-standard fonts are used in the document. Page backgrounds and some other stuff like that are described in a document wide manner also. So some part of page description is outside the page anyway unless each page is produced as a separate PDF document.
Yes, DSC helps — but they are conventions, and not all PS generators use them or use them correctly.
I’m not saying it cannot be done with PostScript, clearly it can. But given the choice of doing it using PDF or PostScript, PDF seems a better choice. That’s one of the reasons Ubuntu has been shipping with a PDF printing workflow for several years now.
[…] ufficiose su un possibile fork, lo sviluppatore Red Hat Tim Waugh, dal suo blog personale, ha annunciato la nascita di printerd, uno spooler di stampa sperimentale realizzato con Richard Hughes. Come […]