[Gnome-print] Some ideas

[Lauris Kaplinski <lauris helixcode com>]

Well, some thoughts about printing pipeline

Terms/objects

1. Printer
Should be physical endpoint of pipeline. I.e. things like FILE, PREVIEW,
UNIX[lp], 'HP LaserJet at secretary's room' can all be GnomePrinters.

2. Driver
Single printer can have many different drivers. The extreme case is FILE,
which can have whatever driver available, but for example HP LaserJet MP
has both PCL and PS drivers. Driver (usually) implements specific subclass
of GnomePrintContext.

3. Profile
Is subset of drivers options, applicable to certain [printer, driver]
set. While PCL driver can have whatever resolution, HP DeskJet 600C has
only certain set of possible resolutions.

4. Context
Is opaque object, interpreting application-side printing. Command given to
context are interpreted, using given profile and driver and routed to
printer, using whatever applicable spooling mechanism.

5. Job
Is floating genie, originating from context and seeking it's way to
printer

Printer settings

1. Routing settings
Which printer to use
2. Printer settings
Filename, to print into, paper tray
3. driver settings
Color, DPI...
4. Application settings
What to print...

How to implement?

GnomePrintManager knows all about:
- printers
- drivers
- routing
- settings and user preferences

Gnomeprintmanager is either kind of library or better yet, separate
process (or manages separate processes)

1. get printer
set printer settings
2. get driver
set driver settings (profile)
3.5 set applications settings
4. Request context
do printing

I think, we can go with following GUI

GnomePrinterSelection
Allows choosing printers
emits "printer_set"

GnomePrinterSetup
Printer-specific widget. Manufacturers can write their own, if they
want. Most basic ones can be built from standard pieces:

TraySelector
DriverSelector
PaperSelector
Resolution selector
Driver-specific setup widgets

Application GUI.

Standard pieces (orientation, what to print)
Specific pieces

Application has to read and interpret it's own settings. If OK is pressed,
it has in addition read following things from GnomePrinterSelection:

printer (char *?)
driver (char *?)
settings - we have to implement some format to transfer these from dialog
to printer driver - to save - and to specify on command-line. All that in
one, manageable (create, ref?, destroy) object.
Should that be PPD - I am not sure. I think we can do with some easily
readable format internally and save preferences as XML.

Then we'll do:

ticket = gnome_print_manager_get_ticket (printer, driver)
pc = gnome_print_manager_get_context (ticket, settings)

ticket is (char *) compact object, that identifies certain print job. It
can used later (when printing context is already closed) to query spooling
status etc.

For command line printing, we can create settings directly from
(string,value) pairs, and request ticket

For special uses (printing to pixbuf, print preview) we can circumvent
ticket (and printmanager) entirely, creating context ourselves.

What printmanager does with ticket?

It manages database of tickets, keeping track of all data associated
with ticket:
- print context
- metafile
- possible spooling system specific data
In most usual cases it creates GnomePrintMeta for users and takes hold of
generated metafile, rendering and spooling it. This happens without user's
knowledge and intervention. Still user can do:

gnome_print_ticket_release - indicates that we are not interested in
ticket any more and it can be forgotten, if job has reached printer (but
manager can well keep it for accounting purposes)
gnome_print_kill_job (ticket)
gnome_print_pause_job (ticket)
gnome_print_resume_job (ticket)
For these functions we implement convenience control center

GnomePrintManager has set of delivery agent implementations (direct to
port, UNIX lpd, CUPS, ...) - but these are not visible from API side.

How to create printers/drivers?

We'll have xml description files for:

drivers (such as PCL)
printers
profiles

printer description files refer profiles (or include these). Profiles
derive from driver descriptions, constraining available options. Drivers
can be derived from each other, so we'll have most generic driver as a
base, and each additional one constrains options.

In addition, there can be:

driver modules (.so, implementing specific context and it's setting
dialogs)
profile modules (implementing setting dialogs)

Comments?

Lauris