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

[Michael Sweet <mike easysw com>]

Lauris Kaplinski wrote:
> ...
> Nope. To get top-quality output, applications should be able to
> intervent every single step in printing process.

I guess we have different goals.  I'd like to see a common, easy
to use printing solution that provides what is needed by 99% of
the applications and users.

> Take adding alpha channel (not yet possible via ghostscript) as
> example:
> ...
> Note, that this process requires complete rendering subsystem in
> client-space.

PostScript and a standard printing interface/printer driver doesn't
prevent you from doing this; in fact, you can generate a printer-
resolution image (with CUPS it is a raster stream, complete with
printer options and a page dictionary) and send it to the printing
system for the drivers to manage if you like.

That's not very efficient, but it's at least as efficient as hard
coding drivers inside applications, and at least the printing
capabilities will be available for all apps, not just a GNOME app.

That said, the traditional use of transparency is masking which
can be done in PostScript with varying levels of ease; Level 1
needs rectangles to define a clipping path, Level 2 can use a
bitmap for the clipping path, and Level 3 provides support for
an image mask bitmap directly.

You can also use "screen" transparency to simulate alpha; SGI did
this with their Showcase program many many years ago, providing
reasonably good results, with the PostScript "code" handling the
resolution details IIRC.

Don't want screen transparency?  Then use your toolkit to provide
RIP'd images where transparency exists, and faster ops where it isn't
needed.

> I very much believe that alpha will be integrated into PS sooner or
> later.

Given the time delay between PS 1, 2, and 3, it will be quite a while.
Also, most PS devices are not continuous-tone and don't have the
memory required for it; compositing halftoned images will result
in terrible output.

> What about 3D (holograms)? Stroke direction (for stone graving) etc.

I'd guess that these are not printing operations that most users
will use, and they will require extremely specialized applications
that will likely not use GNOME-print to interface with their
respective output devices.

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

Such as?

> Just remember, how long it took and how much incompatible variants
> came out, before PS level II included color. If rendering is done

PS Level 2 has always included color support.  Perhaps you are
thinking of Level 1 PostScript, which originally only supported
B&W printers?

> completely in server, and user cannot intervent, new technologies
> take considerable more time to be implemented.

I don't think you understand - applications can ALWAYS provide
their own rendering/imaging stuff.  The main problem we have with
embedding printer drivers in GNOME-print is that THOSE DRIVERS ARE
NOT AVAILABLE TO ALL APPLICATIONS AND THAT WILL PREVENT THOSE "NEW
TECHNOLOGIES" FROM BEING USED AT ALL!

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mike@easysw.com
Printing Software for UNIX                       http://www.easysw.com