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

[Federico Mena Quintero <federico helixcode com>]

>  Nope, just puzzled that you want to implement printer drivers and
>  RIPs *inside applications*, when they belong in other places. 

OK, this discussion is getting a bit out of hand.

As far as I can see it, there are three separate projects:

	1. Making GNOME provide a nice printing framework for
           applications.

	2. Making the GIMP print nicely.

	3. Making a printing system for Unix.

They all overlap to some extent.  Let's layer them some.

The GIMP is an application.  As an application, it should use whatever
APIs are provided by the system.  In terms of the printing
functionality it needs it is pretty simple; it just needs to send the
final composited image to the printing system.  OK, it is not that
simple, but this will suffice for the sake of the discussion.  Since
Unix provides absolutely no printing API, let's assume the GIMP uses
the GNOME printing framework.  Don't yell at me yet, read on.

The goal of the GNOME printing framework is to provide 

	a. A nice API for applications that want to print.  This
	   includes the imaging model, administrivia such as paper
	   sizes and available fonts, and other niceties such as
	   having a GUI to configure booklet creation (n-up plus
	   reduced printing).

	b. WYSIWYG print preview functionality.

	c. Something that my grandma will be able to deploy and use.
	   She doesn't have an imagesetter in her bedroom, she doesn't
	   want to do prepress work; she just wants to print greeting
	   cards and recipes every now and then.

Of course if the underlying Unix system provided a decent printing
system, big chunks of the GNOME printing foo would not be needed.

A Unix printing system should be able to handle:

	R. Home users - Hit File/Print and the damn thing Just
	   Works(tm).

	G. Enterprise users - Accounting and sharing printers on the
	   network.

	B. Prepress work - Any application should be able to print its
	   stuff and not worry about separations, color matching, and
	   other stuff.  Or they should be able to worry about them if
	   they want.  If this means that apps have the option of
	   sending their data in a uniform color space, so be it.  If
	   this also means that applications should also be able to
	   get information about the printer's imaging capabilities,
	   so be it.

So the big things are accounting, printer sharing, and
prepress-related fun.

The traditional solution is to have applications generate PostScript,
and then have some hack to replace/enhance LPD.

Let's look at the disadvantages of this.

Generating PostScript is not hard for applications until you have to
implement the document structuring conventions in every one of them.
Yes, Postscript lets you just spit

	/Helvetica findfont
	72 scalefont setfont
	72 72 moveto
	(Hello, World!) show
	showpage

but this is hardly friendly to a printing system.  To do any
meaningful accounting you have to rely on the printer to be able to
provide you with such information.  Doing it in software would require
having your own PostScript interpreter with accounting capabilities.

This is also not friendly to something that wants to provide good
print preview functionality.  You will need a very smart PostScript
interpreter, rasterizer, and some functionality to store the whole PS
output so that if the user wants to zoom in/out of the print preview,
you won't have to keep enormous bitmaps around.  I.e. you need some
sort of GnomeCanvas-like functionality.

You also don't want to generate a lot of magic PostScript code to deal
with missing fonts, a particular printer's capabilities (i.e. what if
you want to generate a bitmap fill tuned to a particular resolution),
and other ugliness.  It is easier to do this in your program if it
needs it; this would also mean that the printing API should provide
you with all the information you need.

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

[I also know antialiasing may not make much sense when printing on
black and white printers; color printers are an entirely different
issue.]

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.

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
combo.  Let's not sweat over this issue.  You need a RIP somewhere,
and it needs to be a software RIP if you only have an inkjet printer
at home; if you can pipe metafile-like data over the network
(PostScript included) to your fancy imagesetter over the network, then
that is good as well.

The same applies to printer drivers.  Things blur when you can run
them as dynamically-loaded libraries, as remote CORBa objects, as
pipes to another process, etc.  Don't sweat over this.

Existing stuff like IPP may provide a lot of the functionality that
GNOME intends to provide.  This is good.  If it is easy to install and
use, normal people, think grandmothers here, will certainly want to
have it on their desktops.

I hope the GNOME people have explained what you need to know about our
goals and needs.

It would be good if people from the GIMP and Unix printing system side
of things could explain what they need.

Then we can factor out the common stuff and make a nicely layered
system that works both for my grandma, for Widgets Inc., and for
UltraPrinting House Inc.

  Federico