Re: [Gnome-print] Re: [Gimp-print-devel] An introduction to gnome-print(fwd)

[Robert L Krawitz <rlk alum mit edu>]

   Date: Fri, 9 Jun 2000 02:49:36 +0200 (CEST)
   From: Lauris Kaplinski <lauris@kaplinski.com>

   > Why exactly do you need to access the underlying rendered buffer at
   > all, anyway?  For raster printers, it's not likely to look anything
   > even remotely like a bitmap in any format you've ever seen, anyway.

   To do special effects server-side, of course :)
   Alpha, fractals, desaturation & similar color effects, lens,
   etc. etc. Implementing not-yet-seen font types etc.

Well, I'll tell you this: it's hard to imagine a worse possible format
than ESCP/2 raster for this purpose.  It's not a nice packed bitmap
that's easy to edit; the bits are sliced, diced, chopped, and
scrambled whichways, and it's certainly nothing like 8 or 16 bit RGB
or CMYK.  For each bit position, you get 1 or 2 bits each of C, M, Y,
usually K, and sometimes light C and light M.  Then you have to deal
with the fact that each line gives you 1/2, 1/4, or 1/8 of the total
bits in that row, that adjacent lines in the file are 2, 4, 6, or 8
rows apart in the image, and that each row is printed more than once.
The output also gives you no clue whatsoever how the file actually is
organized in many cases (you need to know exactly what printer is
being rendered for to decipher the file).  Sometimes it's possible to
guess by looking at exactly what commands are embedded, but not
always.

This language is a microcode, designed to be convenient for a simple
microcontroller and a small amount of RAM to interpret for a physical
printer and print head.  It has different dialects for every single
printer model.  It is not a reasonable representation of a bitmap.

If you have any doubts about this, I would be most happy to send you a
sample output file, a pointer to the Epson developer web site, and a
little perl script I use to lex and very minimally parse the output,
and let you figure out how to recover the original RGB image.  I'll
even tell you what printer model it's printed for and what the three
undocumented commands in the file are and which two of them you can
safely ignore.  If you'll give me a bit more time, I'll figure out the
gamma and density settings I used in printing, the ink levels used in
the printing, and a general description of the dither method used.  I
trust that if you try this, the experience will cure you once and for
all of any notion of using printer native format as any kind of
interchange mechanism.

   As of raster, it can always use some nice intermediate format (I do not
   know the correct name, but couldn't the one of eye pigmens used?) plus
   access methods for RGB.

Leaving aside the fact that any kind of raster format discards
information about fonts and any other high level constructs, ESCP/2
raster also loses information about the original bitmap (think about
the fact that RGB's color gamut doesn't match CMYK's).  For that
matter, people serious about their printing don't do their editing in
RGB space anyhow, so you're not even helping them.

-- 
Robert Krawitz <rlk@alum.mit.edu>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf@uunet.uu.net
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton