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

[Lauris Kaplinski <lauris kaplinski com>]

On Thu, 8 Jun 2000, Robert L Krawitz wrote:

>    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.

No. Access to rasterized buffer should not mean access it in 
printer-native mode. Driver should be intelligent enough, so if printer
accepts data in some weird format, it could generate
(Alpha/Beta/Rho?) temporary raster image, let user procedure to draw into
that, and convert it then to native mode.
Currently the ONLY way to do that is in client space ;(

>    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.

I am not printing professional, but doesn't the 
(Alpha/Beta/Rho?) colorspace describe ALL possible eye experience?

Lauris