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

[Lauris Kaplinski <lauris ariman ee>]

On Wed, 31 May 2000, Michael Sweet wrote:

> Miguel de Icaza wrote:
> > 
> > We go one step further and we use the Bonobo component technology and
> > OAF, which actually implements (1) and (2) and can even implement
> > (3).
> > 
> > This just adds a dependency on Bonobo/CORBA and requires us to
> > standarize on some bits in the OAF name space, but in the end it is
> > the right solution.
> > 
> > OAF can talk to other remote OAFs and can locate, activate, launch
> > servers both locally and remotely.
> 
> Oh goodie, yet another unnecessary heavy layer that reinvents IPP.
> 
> First, applications shouldn't be responsible for being printer
> drivers; it may be fine if you have GNOME (or XYZ toolkit) application,
> but it doesn't translate into support for all applications.

Nope. To get top-quality output, applications should be able to intervent
every single step in printing process.
Take adding alpha channel (not yet possible via ghostscript) as example:
While printing, save all printing commands to array
If semitransparent image is encountered:
- calcualte its binding box and clip path
- find real output resolution
- allocate new bitmap
- replay previous printing to buffer
- send that buffer to printer
Continue, until next semitransparent image
Note, that this process requires complete rendering subsystem in
client-space.

I very much believe that alpha will be integrated into PS sooner or later.
What about 3D (holograms)? Stroke direction (for stone graving) etc.
PS and server based rendering is nice, as an option, if you have only
basic requirements, but will present intolerable intertia for every new
and advanced technology.
Just remember, how long it took and how much incompatible variants came
out, before PS level II included color. If rendering is done completely in
server, and user cannot intervent, new technologies take considerable more
time to be implemented.

Lauris