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

Re: [XaraXtreme-dev] Printing on Linux

Carl Worth wrote:

On Sun, 11 Jun 2006 21:46:58 +0100, Alex Bligh wrote:

I've been doing some investigations re printing on Linux.



An excellent thing to do. I haven't read through this whole thread yet,
but I do want to make some comments on the background material you
present here, to ensure you're aware of current developments in the
area of printing on free software operating systems.


Thanks for this, Carl.


That cairo for printing "isn't there yet" is technically correct, I
suppose. But it is close enough that I think it should be seriously
considered for any new development. This involves new code in both
GTK+ and cairo, which is currently available in development snapshots
(GTK+ 2.9 and cairo 1.1) but will very shortly be available in stable
releases (GTK+ 2.10 and cairo 1.2). I think both of these releases are
expected before the GUADEC conference at the end of the month (I know
cairo's is).


Sure. But sadly it isn't quite as simple as that. Aside from the
dependency on Gnome 2.9 and Cairo 1.1 (which aren't on any shipping
distros at the moment, obviously), in order to USE Cairo for
anything useful, we'd need DC primatives that call it. So for instance
to use Cairo's graduated fill types, we'd need to make a call to
GTK to do a graduated fill. As our "OS" route of drawing is via
wxWidgets DCs, this would mean someone has to implement the
extra drawing richness in wx. Otherwise OK we'll "use" Cairo (well,
we'll get that for free anyway if GTK does) but not for anything
actually useful :-)


The cairo stuff changes this in that "print to PDF" becomes a real
option that is much more interesting than simply converting PostScript
to PDF. Also, the cairo stuff enables a future change where the
underlying print system could switch from PostScript to PDF as the
spool format with no change in the application.


That's probably the main thing Cairo would give us right now
TBH. However, the trouble is that we still rasterize everything.

I also wonder whether going camelot->wx->gtk->cairo->pdf would be
improved by just going camelot->cairo->pdf (that's a
"CairoRenderRegion" in camelot-speak, or
"Camelot->FilterSystem->Cairo->PDF" or
"Camelot->FilterSystem->PDF"

The advantages of the two routes with "FilterSystem" in the way
(see other thread) is a third party can write a completely
independent executable that takes enumerated .xar file constituent
items (with the relevant bits pre-converted to bitmaps) and
do whatever it likes with them.


At the GTK application level, GTK presents two libraries for use
in printing: libgnomeprint and libgnomeprintui.


To pick a nit here: GNOME provides the libgnomeprint interfaces. GTK+
has never had direct printing support until the recent 2.9 stuff in
preparation for GTK+ 2.10.


Sure. I think that's me getting GNOME and GTK mixed up.


The new GTK+ printing support provides a
printing dialog and allows the application to print in at least two
different ways, (by providing PostScript output directly or by
providing a callback function that will be handed a cairo context to
be drawn on for each page).

Ignoring for the moment any application requirements to work with old
versions of GTK+, I would strongly discourage any new development from
using libgnomeprint. That library is in the process of being entirely
deprecated, with new development being encouraged to use the printing
support in GTK+ instead.


Our reason for using libgnomeprint (well, actually NOT using it
as in general I'm advocating just using the postscipt path, in
which case we'd use libgnomeprintui) is simply that it's what
wx uses. We wouldn't be calling libgnomeprint directly. Just plotting
stuff via wx.


I know the primary developer of the GTK+ printing support, (Alex
Larsson), quite well, and I know he will be happy to help with any
effort to use this code---he definitely wants to fix any limitations
it has with respect to what applications need/want.

In contrast, I think you'll have a hard time finding anybody
interested in doing any maintenance on libgnomeprint, (though it is
more mature so maybe it won't need much).


Sounds to me like we should encourage him to talk to the wxWidgets
folks.

But as I said, my preferred route at least initially is just to
print postscript out. To me, the fact that the underlying printing
system is changing is a great reason /not/ to spend too much time
getting the current libgnomeprint-based wx stuff working.


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);


I can't comment much on wx stuff. I don't know if it is actively
tracking recent print support in GTK+ or not. So there might be a
speed bump there in terms of getting access to the new GTK+ stuff
through wx---though I really don't know.


I know there is at least one wxWidgets developer at GUADEC (hi Mart)
so perhaps we can get the low-down there.


And I'll stop commenting now that you're getting into Camelot-specific
issues, since I'm less informed there. (I do still want to hook up
cairo-based export to Xara which would provide PNG, PDF, SVG, and
PostScript (and by extension, printing support)), but I'm just waiting
for the rainy Saturday afternoon when I can sit down and do this, (and
the time I need to spend before that to have my employer sign off on
me personally executing the Contributor's Agreement).


Export /to/ Xara (i.e. write a .xar) or export /from/ Xara? In any
case you should persuade Gerry to braindump his filter stuff which
will allow Xara to read and write cairo files and vice versa without
actually patching the app as a first step (assuming you are
short of things to do on rainy afternoons).


Anyway, I hope that helps clarify things.


Yep. Thanks a lot.

Alex