Announcing printerd

Posted May 23, 2012 19:48 UTC (Wed) by butlerm (subscriber, #13312)
In reply to: Announcing printerd by drag
Parent article: Announcing printerd

My main criticism here is that Postscript is extraordinarily inefficient, insecure, and awkward as a standard interface from applications to printers and print spoolers. Because it is Turing-complete, a print job can take an infinite amount of time to run, and it is difficult to manipulate. Not only that, most actual Postscript interpreters are riddled with subtle bugs.

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?

Announcing printerd

Posted May 23, 2012 20:30 UTC (Wed) by nybble41 (subscriber, #55106) [Link] (5 responses)

> As a consequence of this common architecture, a Turing-complete programming language ... is massive overkill for contemporary printer interface. ... A high performance page rendering interface should be based on ... a serialized version of OpenGL.

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.

Announcing printerd

Posted May 24, 2012 0:26 UTC (Thu) by nix (subscriber, #2304) [Link] (1 responses)

Shaders?! You do realise that most printers are used mostly to print text, or bitmap representations of text, and that rendering text via shaders is insanely resource-expensive?

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.

Announcing printerd

Posted May 24, 2012 2:53 UTC (Thu) by nybble41 (subscriber, #55106) [Link]

I'm talking about vertex and fragment shaders, in OpenGL terms, not generating text via shader programs. The scene graph would include the text as references to glyphs, and any required bitmaps in the form of textures. The shaders would be handling transparency, gradients, smooth scaling, and other visual effects, just as with rendering to a display.

Announcing printerd

Posted May 24, 2012 8:30 UTC (Thu) by butlerm (subscriber, #13312) [Link]

>A network-attached printer ought to be able to perform its own rasterization, to conserve I/O.

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.

Announcing printerd

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.

Announcing printerd

Posted May 24, 2012 18:35 UTC (Thu) by butlerm (subscriber, #13312) [Link]

> the only plus is that it can start printing when it completed the image of the first page.

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.

Announcing printerd

Posted May 24, 2012 18:02 UTC (Thu) by jsanders (subscriber, #69784) [Link] (1 responses)

I think you are mistaken if you think PDF is not a programming language. PDF is just a packaged-up subset of PostScript, with some enhancements and conventions for adding metadata. It's true that PDF doesn't have the full freedom PostScript has (like being constrained to one page at a time), but it really is a programming language.

Announcing printerd

Posted May 24, 2012 18:25 UTC (Thu) by jsanders (subscriber, #69784) [Link]

Oh, it turns out in my ignorance, PDF is much more of a subset than I thought... I thought it still had control structures, but they are not there.