RFC: A draft proposal for the future of the GNOME printing system.

[Damien Diederen <diederen swing be>]

RFC: A draft proposal for the future of the GNOME printing system.


I have been wondering for quite a time if the GNOME team was going to
ditch the long-standing UNIX tradition of PostScript printing in favor
of a Windows-like printing system.

While I agree that the current scheme -- even if it is well suited to
UNIX servers talking to PostScript printers -- is less than optimal for
simple desktop publishing software running on a workstation and printing
to a simple inkjet printer, I'm pretty confident that the problem has more
to do with a lack of a simple, elegant API than with the classical UNIX
printing pipeline.

The more I think about it, the more I'm persuaded that the PostScript
printing scheme has a lot of advantages over the 'printer-driver-in-the-
app' one, which I will try to summarize below. I have also included the
draft of a proposal for a backwards-compatible and pretty clean printing
framework.

The deal here is not to create yet another printing API, but simply to
discuss and improve the low-level GNOME print architecture. This document
only expresses some of my concerns, and has been by no means approved
by the GNOME leaders. I would be glad if some of my thoughts were
clarified about the shortcomings of the proposed architecture. I would
also be glad to design, work on and eventually maintain an implementation of
this architecture to the extent of my possibilities.

Please remember that this document has evolved from a list of thoughts and
has no real structure. If this is of interest for anybody, it may evolve over
the time, but I preferred to post it now, in the Free Software tradition :
``release early, release often''. There are also a lot of grammar and 
spelling errors, since English is not my mother tongue -- sorry for the 
inconvenience.



1) Summary of the advantages of an improved UNIX printing architecture over
a Windows-like printing system (WPS) -- even in the case of low-end
and slow inkjet printers :


* Spool size : Current systems use a printing daemon which sends data
to the printer in background. It is of course more space efficient to 
store data in a PDL (Page Description Language, e.g. PostScript) than
to store the raw raster data, especially in a multi-user system. 
Moreover, a vast majority of applications (word processors, diagram
applications, DTP systems) inherently work with vector data. A PDL could
also provide additional goodies like high-quality server-side scaling 
of raster images to simple applications.

* Network efficiency : For the same reason outlined before, it is 
more efficient to send PDL than raw raster data over the network.

* Load balancing : In an enterprise setup, the printing server will do
the rendering in place of the client station. This will enable system
administrators to dedicate a box to printing services, freeing the
clients of the tedious and CPU-intensive task of page rendering.

* Driver installation : In a networked printing setup, it is far easier
for system administrators (and far cleaner, too) to only install printer-
dependant data and programs (drivers) on the server. A Windows-like
printing architecture requires that drivers for each and every
network-accessible printer be installed on each workstation.

* Special printer features : The GNOME framework could provide application
with an easy access to PPD files data and peculiarities. PPD-style 
printer description files could be created for non-PostScript printers
and installed on the server (e.g. an XML file describing printer options
and available resolutions with SANE -- Scanner Access Now Easy -- style
options could be accessed as : 
'http://printserver.acme.com/printers/hp895cxi.xpd').

* Alpha channel support : Most applications won't need alpha channel
support and it will be extremely difficult to get it 'Just Right' on
real PostScript printers. For other printers, it would be interesting to
see if GhostScript is 'hackable' to include PostScript extensions like
'1 0 0 0.5 setrgbacolor'. Alpha channel emulation for PostScript printers
would still be envisageable as a client library.

* Device colorspaces : PostScript already provides a lot of color
management schemes. There is no need to reinvent the wheel and provide 
GNOME with a load of CM APIs. The people writing graphic apps
are probably aware of the CM options PostScript has to offer.

* Sudden system load : In a WPS (Windows Printing System)-type architecture,
the application is blocked for a long time while printing a complex
document (it has to render it, which takes a lot of cycles -- CPU 
activity goes to the roof -- and this is not really a joy to cope with on a
multi-user system). The application could be multithreaded or anything, but
this introduces a lot of complexity and possible races, and has been proven to 
fail in practice (printing on a Windows box is a nightmare). Even on
a single machine, GhostScript installed as a filter only produces raster
data at the rate it can feed it to the printer -- much more elegant, and 
doesn't unnecessarily introduce *huge* temporary files.

* PostScript procedures : PostScript being a real computer language,
custom procedures and graphics can easily be downloaded to the printer
(or the print server). This gives a real advantage memory-wise (think of a
corporate logo that appears on each page here) versus the dumb 'print it
N times' scheme.

* Manipulation of application output : If the application outputs DSC
compliant PostScript, power users can easily squeeze filters into
the printing pipeline to achieve interesting effects, like multiple logical
pages per physical page (psnup), even/odd printing, etc. without even
requiring the application to have knowledge of these possibilities. A system
administrator could define a 'draft' printer which automatically draws two
pages per sheet of paper.

* Printer feedback : My understanding is that the application *should not*
be notified of the job success/failure. While this may sound unintuitive to
Windows users, there is no reliable way to guarantee that the job will be
handled immediately, and that the application will still be running when the
job is done (look at the horrid face of Windows users when their printer
starts executing old jobs at bootup time ;). The application should be notified
of spooling failure, though. It would be the job of the daemon to 
notify *the user* of printing failure (or success on demand) by mail.
If the daemon were aware of the PostScript language, 'decent' print reports
could be constructed (using DSC comments, for example) :

``
Your print job #123, submitted Wed Mar 29 11:11:24 CEST 2000
by the application MicroSoft Word for Linux has failed for the
following reason(s) at page 3 : 

Invalid PostScript extension : mslogoalloverthepage

If the problem persists, contact your system administrator and show him
the following stack trace :

-------------------------------------
Error: /undefined in mslogoalloverthepage
Operand stack:
   [blah]
Execution stack:
   [blah, blah]
Dictionary stack:
   --dict:904/941(G)--   --dict:0/20(G)--   --dict:50/200(L)--
Current allocation mode is local
Current file position is 21
-------------------------------------
''

The user should be able to click a checkbox to receive job termination
and success confirmations by mail as soon as the sheets are out of the
printer. An additional DSC comment like '%%GPrintSuccessNotify: true'
could be handed to the daemon.

* Application components : If PostScript printing were agreed upon, application
components (let's say a chart in a Gnumeric) could request information to
the application at printing time (resolution, colorspace, etc -- this is
necessary for proper raster image handling, even if PostScript in itself is
device independent), and then output a clean and *clever* EPS stream. There
would be no need to reimplement a new metafile format. It would also work
flawlessly with a GGV-like print preview system. 

* Print preview : It would be a pity to ditch PostScript as a general
printing technology, while Display PostScript is being implemented 
in XFree itself, and has been available for a while on a lot of X servers.
PostScript-like primitives and extensions (Alpha, Shaders) for XFree are being 
worked on, by the means of a libart-like high-quality rendering framework. 
All these pieces would fit nicely.

* Debugging aid : Developers could carefully examine the PostScript code
output by their applications, view it at any zoom level, etc., test it
in a multiple PostScript interpreters, etc., without actually printing
a single sheet of paper (installing a PostScript driver in a WPS-like
architecture is *not* an option : One could break other printer drivers
without even noticing it, as the difference between printer drivers is
far worse than the difference between PostScript interpreters).

* Clever hardware : While manufacturers design more and more clever video
hardware (like the GeForce with built-in geometry), the current trend is 
to create dumber and dumber printers. Misinformed users are ready to lose
important processing power to accomodate ill-designed hardware like 
WinModems and WinPrinters (is the common Win- prefix an accident ?).
A printer buyer's guide should be written that describes the design
of the printers (and not their PPM rate under NT, not accompanied of any 
system load information) before there are no more good low-end printers
around. 


2) Simple proposal of a method to enhance the UNIX (and particularly
GNOME) printing architecture :


I feel that it would be really better to shift the development of 
GNOME-Print towards a PDL architecture using PostScript as a language
(no need to reinvent the wheel, and it is an interoperable de-facto 
standard). The GNOME project could provide application writers with
a good set of features and APIs to drive the system. 

Having thought about it for a few days, I can envision the following
possibilities, spawning across a few modules :



** libgprint (core, depends only on glib, and is available for text/X/
KDE/Gtk/GNOME-based applications) :

* PPD (PostScript Printer Description) and XPD (XML Printer Description,
for non-PostScript printers -- see above) parsing into well-defined
data structures. The XPD (PPD sould definitively be wrapped by XPD
descriptions) file would contain information on available printer
resolutions, paper types, etc., snippets of PostScript/GhostScript code
to set them in the printer, as well as GLADE-style descriptions of printer
options dialog boxes (beware of interoperability problems here).

* XPD file downloading. This could be implemented as a simple ftp-like
protocol as well as a full-blown HTTP application (requiring a 
libwww dependency). The app should be able to list or query the 
printers available on any print server to which it has been
authorized to connect.

* DSC-aware PostScript creation functions : g_print_document_begin/end(),
g_print_prolog_begin/end(), g_print_page_begin/end(), etc., as well as
a set of functions to set metadata in DSC comments (%%GPrintFooBar: -1).

* Font/Resource conditional loading : A set of functions dealing with
the XPD files to conditionnaly load printer fonts and resources, e.g.
'g_print_cond_load_font(context, "Times-Roman", flags)'.

* PostScript code snippets loading and downloading : A set of functions
enabling the app to load *at runtime* (to the contrary of the pswrap 
program from DPS) PostScript code snippets and to send them to the printer :
g_print_snippet_load("snippets.xml"), g_print_snippet_send(context,
snippets, "drawacmelogo"), etc.

* Daemon communication facilities : A set of functions enabling the 
application writers to query printer status (Ready, Printing, Offline, 
Unreachable), as well as submitting jobs to the daemon (complete,
with metadata support). 


** libgprint-gnomeui (User Interface, could provide a high-level,
tookit-dependant API to GNOME applications -- other teams would have to
provide the -cursesui/-kdeui counterparts) :

* Printer options dialog creation : Functions to automatically create
an option dialog from information contained in the XPD files. Ideally,
this would create a full-blown GtkObject that the application would just 
have to query to get the printer initialisation code and the chosen
resolution/mode.


** libgprint-bonobo (Bonobo objects for the Bonobo framework) :

* Provides Bonobo objects representing printer selection dialogs and
printer-specific option dialogs.

* Provides BonoboGhostScript, a simple component providing applications
with a real and accurate (Color Managed) print preview, or arbitrary
PostScript embedding, either by converting GhostScript to a shared
library, or by sub-embedding it as a GGV bonobo component. The GGV
based approach would offer the user a consistent interface between 
dealing with PostScript files and print previews (with all the
zoom, page selection, etc. features inherent to a PostScript viewer). A 
power user could even be able to select the pages he wants to print without
the application even noticing (we all know about bad software that doesn't
allow page ranges to be easily specified -- especially even/odd cases).


3) Conclusion :

This kind of framework would open a lot of possibilities for high-quality,
user-friendly and easily manageable printing on UNIX-like systems.

Ideally, GhostScript should be hacked (if this is possible, I have not
investigated further) to support dynamic module loading (installing a
printer driver should be just the matter of putting the right files at
the right place) and alpha channel. Each printer driver should be
accompanied by an XPD file describing the features it provides, 
as well as the PostScript extensions availables (Alpha channel,
Shaders, etc.) for the app to query. Those features would render
printer administration very easy for power users and distribution
maintainers.

Another thing to consider is the /coolness/ factor of such an implementation.
People and developers are going to love GNOME because it is easy to use,
powerful, easy to program for and fun. Runtime loading of GLADE files, 
a Turing-complete window manager (Sawmill), the Canvas and ORBit are 
all great features, but they would be nowhere if they were not 'interesting'.
It is the job of the GNOME people to provide the GNU community with an
interesting and hacker-friendly printing system.


Damien Diederen

dash@linuxbe.org
http://users.swing.be/diederen/


-- 
* Pétition contre les brevets logiciels : http://lln.udev.org/sign.php3
-- 
Damien Diederen
dash@linuxbe.org
http://users.swing.be/diederen/