Recent Features
| |||||||||||||
Announcing printerdAnnouncing printerdPosted May 23, 2012 20:30 UTC (Wed) by nybble41 (subscriber, #55106)In reply to: Announcing printerd by butlerm Parent article: Announcing printerd
> 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.
(Log in to post comments)
Announcing printerd Posted May 24, 2012 0:26 UTC (Thu) by nix (subscriber, #2304) [Link]
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] 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.
|
|||||||||||||