[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]

Re: [XaraXtreme-dev] Printing on Linux

Phil,

--On 12 June 2006 10:28 +0100 Phil Martin <phil@xxxxxxxx> wrote:


As you say, we would still need to retain the OS printing route ready
for when LX runs on Windows again. And we must be careful to not  break
that route in making printing work on Linux.


Sure. I wasn't thinking we should touch it.


Both the OS printing route and the PS printing route in Camelot need
similar UI and similar scanning code to work out which parts of the  tree
need to be flattened into bitmaps and which can be rendered  directly by
the current printer (driver). So, I don't see why the PS  print route is
supposed to be simpler than the OS print route...???


Quite simply because we'd have to make all the OSRenderRegion stuff
talk to the wx rendering primatives correctly, make sure there were
no pixel inaccuracies, where there were then work around these with
a different set of hacks to the current hacks when windows gets things
wrong etc.; further, the OSRenderRegion route has lots of nasty hacks
(look at the route for plotting bitmaps) on Windows and it's not obvious
whether these are necessary to keep on all platforms, need keeping
only Windows, or needed keeping for (say) Win32s on Win3.1 but now
are moribund. If we add yet another layer of hacks on top of that,
it seems to me it will be impenetrable.


If we use libgnomeprintui (you said libgimpprintui but I think you  meant
libgnomeprintui)


Yes


would we be bypassing the wxWidgets printing  framework?


No. We'd use the wxWidgets UI framework to call libgnomeprintui (hence
the necessity to compile wxWidgets with libgnomeprint sepecified).


If we were creating Postscript ourselves and injecting it  into gnome
printer drivers would we be bypassing the wxWidgets  printing framework
again? Either of those things would make it more  difficult to port LX
back to Windows (and other OSs).


We'd be sending postscript direct, rather than rendering into the wxDC.

I don't see why this makes things more difficult. OK it doesn't
make it easier because we get to avoid the work of making wxDC based
printing work. So if on platform X (for instance MSW) wxDC based
printing is needed because there is no underlying PS-based engine,
we'd need to do that work at some later date. But given it is all
disabled at the moment, I don't see why reenabling the PS stuff as
the main Linux route is a bad idea.

Put it this way. Let's say we get ps printing to work. What would we gain
(on Linux) by reenabling OSRenderRegion based printing through a wxDC? I
think the answer is "nothing at all - it would print to PS anyway and do a
worse job than us". For instance, wx has no grad filled shape parameters.
So even linear gradfills would always be rasterized rather than stepped &
clipped. The PS route, we have a choice. They then won't be rasterized in
(say) PDF or HP. That makes a huge difference to print job size in (for
instance) an A4 page with a single linear background gradfill, where 255
steps is quite adequate. If we went via WX, you'd necessarily have a
complete page bitmap 100% of the time.

Alex



Phil


On 11 Jun 2006, at 21:46, Alex Bligh wrote:


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