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

Re: [XaraXtreme-dev] Printing on Linux

On Mon, 12 Jun 2006 20:00:45 +0100, Alex Bligh wrote:
> 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.

Yes. There's still the question of how married you are to wx APIs for
rendering. (Obviously, I have my own preference for cairo's APIs and
its own support for multiple backends, but you know that...)

But the GTK+ printing support isn't just about cairo. It also provides
a print dialog through which you can feed PostScript directly to the
underlying print system, (without needing to use cairo for rendering
at all). And that's supposed to be better than libgnomeprint in
various ways, (avoids adding dependency on libgnomeprint and bonobo,
adds win32 support, add ppd support, etc.). So there are other
benefits here even if you don't touch cairo at all.

I'm just not the best better to describe what those benefits are. I
assume one would get better cross-platform support out of the GTK+
print dialog than libgnomeprint. And there's probably 

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

Right. If you're just using wx rendering interfaces for your printing
then it won't provide access to cairo benefits until someone made wx
emit stuff through cairo. I don't know if anyone has ever looked at wx
+ cairo integration.

But it sounded to me like you were exploring various paths for
rendering your print output, so cairo might make sense. As you say

> 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"

which, yes, looks much better. If you're trying to get the benefits of
cairo, then putting wx in the way doesn't make a lot of sense.

> 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 should have been more careful myself. Whenever I said libgnomeprint
I was referring to either libgnomeprint or libgnomeprintui. In one
sense, the new way is that cairo provides the rendering interface to
replace libgnomeprint while GTK+ 2.10 provides a print dialog to
replace libgnomeprintui. I imagine that upstream wx will pick up the
new print dialog without needing too much encouragement.

> Export /to/ Xara (i.e. write a .xar) or export /from/ Xara?

Exporting from Xara. I'd like to implement Xara filters for exporting
designs as PNG, PDF, or SVG through cairo (of course, all three of
those come with a single investment of effort). 

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

I'm not sure what you mean by "cairo files" since no such thing
exists, (cairo is just a library interface). And what do you mean by
"without actually patching the app" ?

What I want to do is start exploring the usage of the cairo interface
within the Xara application. And it seems like something like a File
menu option of "Save as PDF (using cairo)" would be a nice place to
start experimenting. So, any braindump to help me do that would be


Attachment: pgpTemPJBuHvK.pgp
Description: PGP signature