RE: [XaraXtreme-dev] Printing on Linux

["Charles Moir" <CharlesM@xxxxxxxx>]

Interesting. So basically you're saying we can rely on doing only Postscript printing because Ghostscript is standard and provides a means of printing PS to any old printer?

If that's the case, you're in effect saying PS is the Linux printing standard, then sure we should rely on PS printing, and forget about any other method. Doesn't make any sense to do it any other way.

But I'd note:
A) Our PS output very out of date. E.g. we don't output any grad fills at all. Everything is stripped in Camelot (and I'd expect to see evidence of this e.g. Moiré patterns or at least banding, in almost all fills if you looked closely enough). It's crude. Very slow and very out of date.

B) I'm not at all sure you can assume Ghostscript is not broken. We had a real tough time getting Ghostscript to render Xara PDF 1.5 files. I recall that that it does not support transparency or masking correctly, possibly more.

I suggest try printing some Xara PDF 1.5 files that contain real vector grad fills and vector grad transparency and see if you can get that to either view or print correctly.

(Of course since our PS printing IS so old fashioned (no grad fills or transparency) this should ensure it will work reliably. It's our PDF output that is bleeding edge (using new PDF transparency and masking) that causes GS the problems.

The print as bitmap case is an option for all our print output and we should keep this. Printing hi-resolution bitmaps is often more reliable (because it's very simple and we just rasterise as we do for screen so your guaranteed 100% WYSIWYG) and nearly always far faster (because of the speed of Xara rasterising) - although bitmap printing on PS devices is far from efficient).

Charles


> -----Original Message-----
> From: owner-dev@xxxxxxxxxxxxxxxx 
> [mailto:owner-dev@xxxxxxxxxxxxxxxx] On Behalf Of Alex Bligh
> Sent: 11 June 2006 21:47
> To: xara-dev
> Cc: Alex Bligh
> Subject: [XaraXtreme-dev] Printing on Linux
> 
> 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
>