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

[Lauris Kaplinski <lauris ariman ee>]

On Thu, 1 Jun 2000, Michael Sweet wrote:

> Federico Mena Quintero wrote:
> > ...
> > you won't have to keep enormous bitmaps around.  I.e. you need some
> > sort of GnomeCanvas-like functionality.
> 
> Print preview != printing.  Applications and toolkits can provide
> this functionality without using PostScript as the internal format.

This is exactly what gnome-print does. And it can output PS as well, so
where is the problem?

> > Also, people do want something better than the PostScript imaging
> > model, the most obvious things being alpha transparency, gradients,
> > and antialiasing.  Most applications don't need these and would be
> > perfectly happy with the PostScript imaging model; the gnome-print
> > looks to them just like the PostScript imaging model.
> > 
> > [I know PS3 supports gradients and other exotic stuff, but most
> > printers are still PS2, so you can't rely on having that
> > functionality everywhere; in that case your RIP will have to
> > generate them by hand.]
> 
> Alpha transparency has limited use in printing; applications that
> use it need to composite the final image before printing anyways
> (whether the app or the toolkit does it, it needs to be done
> before the printed image is generated, right?) so this is a non-
> issue.

This exactly is the issue. If toolkit does this anyway, it has to include
full-featured rasterizer. And I can see no reason, that rasterizer cannot
output some neat PCL/ESC/P2 too...
On the other hand: Take 20 overlayed semi-transparent A5 rectangles on A4
page. Unless printer driver can intercept into PS job very intelligently,
printing such beast via PS take 10x more memory, than printing single A4
pre-rasterized page.

And the reason few people use semitransparent shapes/text/images in
printing is not that they do not need these, but this simply had not been
possible until recent times.

> > Your underlying printing system *still* needs to handle PostScript
> > input, since legacy apps will require it.  This does not mean that
> > you need to go for the lowest common denominator and screw all new
> > nice and pretty applications.
> 
> So far you still haven't brought up a single example of printing
> that *can't* be done via PostScript.

There is no such example. PS includes turing complete language, so in the
worst case your print job can render itself to bitmap ;)

My suggestion: holograms

> > As far as where the RIP functionality goes, it is a moot point.
> > Applications don't care whether it is loaded as a shared library or
> > if metafile-like data is sent over the network to a RIP->imagesetter
> 
> Um, *I'd* care if the resident size of my app is 1MB or 2MB, or if
> it requires 15 DSOs of just the right version to work.

Some desktop users also care, if printing on their machine requires 4
different programs of just right version numbers, depending on unknown
number of rarely found libraries, or just 2 programs, depending on few
huge, but well known libs.

Lauris