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

[Miguel de Icaza <miguel helixcode com>]

> Printing costs money.  Therefore, businesses, colleges, the military,
> etc. want to track who is printing, what they are printing, etc.
> Printing raw data makes this task nearly impossible, and like I say
> below doesn't solve the printing problem for non-GNOME apps.

I am really really confused.

How can you tell from a 10 line Postscript program how much ink and
paper is generated on the printer without printer help?  Or how can
you tell if a 200 megabyte postscript file generates a single page or
kills the entire amazon rainforest?

> How many DSOs (drivers) would you need to support sll of the
> popular printers?  If you have N printers, do you need N DSOs?
> How does GNOME-print discover printers, how does it discover
> drivers?

I do not know the answer off hand, but it is good to hear your
concern.

Off the top of my head, I would say:

	1. Every driver consists of an XML file that describes the
           properties of the printer: name, vendor, shared object that
           implements it, unique features, features that need to pop
           up on a config dialog.

	2. Those XML files get droppped in a special location in the
           system.  The runtime uses those files to show a list of
           drivers on the system.

	3. Shared objects implement are the "engine" that actually
           drives the printing process and they are loaded by the
           runtime on demand (after looking at the XML description
           file) and initializat themselves from the description file
           plus any system global settings, plus any user settings.

You dislike shared libraries?  No problem.  

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.

Love,
Miguel.