I've been doing some investigations re printing on Linux.
The Linux printing system is somewhat different to the MSW one in that
fundamentally it is postscript based (whether or not your printer is
postscript). The underlying file based printer driver (lpr) can be
sent a postscript file on a modern Linux. If the printer is a
postscript printer, the file will simply be sent to the printer.
If not, and a filter will cause Ghostscript to render it. The printer
drivers themselves hook on as Ghostscript output devices, and can
render either via a bitmap or directly.
There are moves afoot to add Cairo as an underlying printing
technology,
but this isn't there yet. Postscript will continue to be supported.
The printer driver technology also supports printing to PDF, in as
much as the postscript is simply turned into PDF.
At the GTK application level, GTK presents two libraries for use
in printing: libgnomeprint and libgnomeprintui. The latter is the
UI library which presents an application-consistent mechanism
of selecting the printer, doing printer setup etc (much like windows).
This is available in wx if wx is compiled with --with-gnomeprint
(it isn't by default, but we shouldn't let that bother us); you
can see this in use by running a true gnome app like gedit. The
print ui has come a long way in the past year, so try a modern one.
You will note that it offers print to PDF by default.
libgnomeprint is a library that allows certain gtk primatives to be
translated into postscript. wx provides a wrapper through its DC
based printing system so that drawing into an appropriate DC causes
the gtk primatives in question to be used, and to produce the
appropriate
postscript output. This is in turn sent to the printer.
However, these libraries are independent. It is possible to use
libgnomeprintui without using libgnomeprint, and vice versa. This
will (I think) be useful to us.
Turning briefly to Camelot, it seems to provide two main methods
of printing on Windows
* Print the page as postscript. Camelot generates the postscript.
The postscript either represents the shapes concerned, or whether
the postscript cannot handle the shapes concerned, bitmaps are
embedded within the postscript. Various tweaks are available.
This I'll call the postscript route.
* Use the OS printer driver route. Camelot renders the page using
OS rendering primatives (osrndrgn.cpp), except for those bits
the OS can't handle, or broken printer drivers handle badly. These
are drawn to bitmaps, and the bitmaps are in turn plotted via
the OS printer drivers. This I'll call the OS route.
There are tweaks available which change the way the drivers behave.
It is possible to force Camelot to render the whole page as a bitmap,
but that appears merely to be a special case of one of the above.
IE either PS or the OS are used to render the bitmap after it's
been plotted.
Now, on Linux, the OS route seems rather redundant. We go through
several translation layers (Camelot primatives, OSRndRegion, wxDC,
gtk primatives) to get to the postscript which we could have generated
directly. Every printer supports being sent postscript. So I reckon
we don't need to do the OS route. But will that make things terribly
slow?
To test this, I created a file based on FillTypesSimple.xar. I
installed
both the PS and non-PS printer driver for my Colour LaserJet 4500N
(a six
year old laser printer). I used Xtreme to produce a postscript file
to send
to this using the default settings. Printing to the postscript printer
either directly from Windows, or by copying the file to Linux and
printing
to the postscipt printer driver, took about 10 minutes. This was
mainly
rendering in the printer.
I then printed the same file to the non-postscipt printer driver. This
invokes Ghostscript, converts the output to HP format using the
printer driver backend, and sends it to the printer. I expected it to
be much slower, but it started printing within 10 seconds. Far far
faster.
Will we have to special-case printing the entire page as a bitmap? As
far as I can tell, no. On non-postscript printers, by default, this
still
seems to go by the bitmap route. The exception appears to be GIMP
which interfaces to the drivers directly using the old gimpprint
interface. However, it's unclear whether this provides any benefits
at all.
Given ghostscript is now used in some commercial RIPs, I think we can
probably rely on it not being broken. I noticed some moire in one of
the conical fill types, but I suspect that's more a problem in our
postscript than anything else.
I'm thus of the opinion that we can satisfactorily handle printing
on Linux
merely by
a) Using libgimpprintui
b) Supporting (only) postscript mode printing, and generating our own
postscript to send to the printer, just like we do at the moment,
and
letting the OS worry about rendering it.
This also has the advantage that we have a well defined basis for
doing
things like colour correction etc.
If there is something fundamentally broken about this, we can always
reintroduce OS mode printing later. It would, however, appear that
printing on Linux may be substantially more simple than printing on
Windows. And I didn't think I'd ever hear anyone say that.
Alex