Announcing printerd
Announcing printerd
Posted May 22, 2012 16:11 UTC (Tue) by randomguy3 (subscriber, #71063)Parent article: Announcing printerd
It will presumably be able to talk to IPP servers (via the relevant cups driver?), which might either run on the local machine (if you sometimes have more demanding requirements, like receipt printing) or on a remote machine (particularly in businesses, for example).
The issue, of course, is the transition period, where everyone will have to support everything. The announcement suggests that there will be a lightweight IPP server available at some point, which could be used to support CUPS-only applications (but negates the on-demand part of printerd), but applications using printerd's D-Bus interface will also have to support cups (or one of its compatibility modes, like lpr) directly to work on systems that don't have printerd.
Posted May 22, 2012 16:56 UTC (Tue)
by drag (guest, #31333)
[Link] (13 responses)
I don't understand the point of writing less capable software just so that when somebody needs to be able to do what is relatively easily done in any other OS they must rip out your software and/or reconfigure their OS.
> It will presumably be able to talk to IPP servers (via the relevant cups driver?),
Typical 'cups driver' is just a postscript description file.
Postscript is a programming language that is used to instruct the printer on how you want you page printed. Cups will take the postscript from your application and then insert additional instructions to it based on the PPD file (aka 'driver') and your configuration dialogs. Instructions on how to handle ink, line speed, stapling, duplex, etc etc.
This is why you need things like Ghostscript, because CUPS must have the ability to tear down postscript 'documents' and then rebuild them for specific printer models.
Then, of course, there are a large number of printers that do not support postscript, proprietary psuedo-ascii line/serial printers, or printing tasks that require other languages like PCL.
On top of all that modern printers are designed to be really stupid. They tend to no longer understand proper printing languages. Instead they are little more then over-glorified USB accessories were you have a proprietary (as in printer-specific) daemon that is able to take the postscript/pcl/etc instructions and transform them to the device-specific instructions necessary to operate the printer head and emulate a traditional printer device.
All and all even relatively 'basic' printing tasks tend to be fiendishly complicated and require a heavyweight solution.
So unless printerd can replace CUPS in it's entirety there is no point in having it do anything except just being a spool manager that replaces some fraction of CUPS functionality.
Posted May 22, 2012 19:23 UTC (Tue)
by butlerm (subscriber, #13312)
[Link] (12 responses)
This is evidence of a dedicated printer mentality. Why in the world should a typical user configure a 'printer' in order to get a specific print job to print the way he wants it to? Users should have the ability to control all of that from within some sort of print dialog in the application.
>This is why you need things like Ghostscript, because CUPS must have the ability to tear down postscript 'documents' and then rebuild them for specific printer models.
A much saner system for graphical printing would be for applications to use some combination of shared libraries to discover what printers are available, what properties they have, allow the user to configure the specific print job, render (ultimately) through a standard API directly to a printer driver loaded in-process, and send the output of the printer driver to the spooler on a local or remote system.
Then the system wouldn't be in the position of rendering to some baroque programming language, and loading and reinterpreting it into something printer specific. X style process separation for the printer driver could be kept if necessary, but the idea that Postscript should be the lingua franca for communication to a printer driver is positively perverse.
Posted May 22, 2012 20:40 UTC (Tue)
by drag (guest, #31333)
[Link] (11 responses)
Configuring a printer from a print dialog is exactly what I am talking about.
You select color quality, line quality, print speed, stapling, collation of reports, and all that stuff. A person must decide this when printing.
That's 'configuring'.
If you want to be able to print anything other then plain single-sided black and white documents then the ability to edit postscript documents and insert the proper printer-specific control sequences on the fly is a absolute requirement.
Depending on the printer you can send usually postscript directly to it. Over a parrellel port or USB port or over IPP connection. It may need to be rendered into USB control sequences for cheapy ones using a proprietary daemon.
> A much saner system for graphical printing would be for applications to use some combination of shared libraries to discover what printers are available,
So you want to distill the functionality provided by CUPS and Ghostscript (and related filters, tools, and programs) into application libraries and then load that into each and every application? How would that work out well?
> Then the system wouldn't be in the position of rendering to some baroque programming language, and loading and reinterpreting it into something printer specific.
So instead you want each and every application will be in the position of rendering to some baroque programming language, and loading and reinterpreting it into something printer specific.
That seems completely ass-backwards. Typically the OS wants to make things easier for programmers to do by providing common functionality instead of making it worse...
Posted May 22, 2012 21:21 UTC (Tue)
by dlang (guest, #313)
[Link] (10 responses)
That's actually almost exactly what is done today. the "baroque programming language" is postscript.
but we've seen what happens when every program needs to adjust it's document to the printer in question, the result is the windows printing mess where loading a different printer driver can change your document layout drastically.
Posted May 23, 2012 1:23 UTC (Wed)
by drag (guest, #31333)
[Link] (9 responses)
Of course. That's why I _said_ it.
Postscript, in this context, cannot be thought of as a document format. It's a printer control language.
It's wrong to treat it like it's a document. It's a scripting language that instructs printers on how to print out documents. And as such it needs to be edited on the fly and based on the preferences of users in different manners for different printers.
Which is why it's important that you use a centralized program to manage this as much as possible. The program should just tell the daemon that 'I want low quality color collated front to back with pages 1-5 stapled together' and have the system deal with it as much as possible.
> but we've seen what happens when every program needs to adjust it's document to the printer in question, the result is the windows printing mess where loading a different printer driver can change your document layout drastically.
That's not surprising since each printer can be drastically different and different PPD files (aka 'printer drivers', aka 'postscript printer description' files) expose different capabilities.
Unless your program can change the document to suite the printer then it's just a guessing game on the part of the user as to how it's going to look when printed. However, obviously you don't want to force every application to be a desktop layout suite. So therefore you want the system to handle as much as the complexity as possible for applications that don't need it.
This is why you will always needs CUPS or something just as complex to replace it. You can't get away from it. Printing is a huge pain the ass.
Posted May 23, 2012 19:48 UTC (Wed)
by butlerm (subscriber, #13312)
[Link] (8 responses)
There is nothing in principle more difficult in rendering to a high resolution printer than in rendering to a display. For a wide variety of reasons, it is uncommon to require applications to generate Postscript fragments to display anything on the screen. Virtually every graphical application uses some sort of internal or library provided rendering API to display output on the screen, why should it use a different one to generate output for printing?
As a consequence of this common architecture, a Turing-complete programming language like Postscript is massive overkill for contemporary printer interface. PDF is much better (because it is not a programming language), but it tends to be a rather inefficient processing format as well.
A high performance page rendering interface should be based on a binary wire protocol vaguely similar to X, or a serialized version of OpenGL. PDF is more than a little inefficient by comparison. Contemporary display devices render hundreds of extraordinarily complex scenes per second.
Is there any fundamental reason why a printer driver can't be as efficient? Or why we shouldn't prepare for a world where nearly all page rendering is handled on the host system rather than by a ridiculously underpowered, buggy, and resource impaired piece of firmware on the printer?
Posted May 23, 2012 20:30 UTC (Wed)
by nybble41 (subscriber, #55106)
[Link] (5 responses)
Modern OpenGL (with shaders rather than fixed-function pipeline stages) essentially _is_ a Turing-complete programming language. For similar reasons, I don't think non-Turing-completeness is a reasonable requirement for any rendering API, and for printing I'd actually prefer something like a scene graph with attached shader programs. Naturally, as with rendering for the display, the shaders would be subject to various resource limitations, including a limit on runtime. It should be possible to rasterize the print job via commonly-available embedded, OpenGL ES-capable GPUs.
> Or why we shouldn't prepare for a world where nearly all page rendering is handled on the host system rather than by a ridiculously underpowered, buggy, and resource impaired piece of firmware on the printer?
A network-attached printer ought to be able to perform its own rasterization, to conserve I/O. For printers designed to be connected only to a host PC, however, I'd just as soon standardize on a simple raster-based printing protocol and do the heavy lifting on the host--ideally with GPU acceleration.
Posted May 24, 2012 0:26 UTC (Thu)
by nix (subscriber, #2304)
[Link] (1 responses)
Like it or not, there's going to be either a bitmap or a vector language (or, more likely, both) in any plausible printer for a very long time to come.
Posted May 24, 2012 2:53 UTC (Thu)
by nybble41 (subscriber, #55106)
[Link]
Posted May 24, 2012 8:30 UTC (Thu)
by butlerm (subscriber, #13312)
[Link]
This is a nice benefit, but the problem is that in most cases it is a program of planned obsolescence for otherwise perfectly adequate printer hardware. Short of mid-range printer manufacturers adopting a standard for rasterizer plugin cards, host (or print server) based rasterization ought to be the most effective way to keep a decent printer from not so gradually turning into an expensive paperweight.
As an example, I have a ~$1K laser printer from a name brand manufacturer that is less than five years old that is in the habit of taking more than a minute to print single pages from innocent looking PDF files. Certainly any well written host based rasterizer could run circles around that.
>Modern OpenGL (with shaders rather than fixed-function pipeline stages) essentially _is_ a Turing-complete programming language.
OpenGL serialization was a poor choice for an example. Something more like a efficient serialization of the PDF rendering model was what I had in mind. A serialization of OpenVG might work nicely, but it appears to be a little too simple.
Posted May 24, 2012 9:00 UTC (Thu)
by pkern (subscriber, #32883)
[Link] (1 responses)
You really want to drive network-attached printers with rasterized input as well. It has the computing power of a toaster, the only plus is that it can start printing when it completed the image of the first page. PDF can have multiple layers and hence may overload a rasterizing printer easily. Even PCL XL is already too complex and certain outputs will cause the printer to take a walk. The only part that worries me about printers that really only take raster input is the fact that you then need to bother with uploading their firmware and the newest and greatest proprietary inventions of rasterization on-the-wire formats to reverse engineer.
Posted May 24, 2012 18:35 UTC (Thu)
by butlerm (subscriber, #13312)
[Link]
If there isn't any serious way to generate and stream a PDF document one page at a time, PDF would seem to be a uniquely unsuitable format for the printing of large documents not already composed and linearized in PDF format in any kind of a hurry. Perhaps SVG Print would be a better long term alternative for that reason alone.
Posted May 24, 2012 18:02 UTC (Thu)
by jsanders (subscriber, #69784)
[Link] (1 responses)
Posted May 24, 2012 18:25 UTC (Thu)
by jsanders (subscriber, #69784)
[Link]
Announcing printerd
Announcing printerd
Announcing printerd
Announcing printerd
Announcing printerd
Announcing printerd
Announcing printerd
Announcing printerd
Announcing printerd
Announcing printerd
Announcing printerd
Announcing printerd
Announcing printerd
Announcing printerd