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 here: > 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 appreciated. -Carl
Attachment:
pgpTemPJBuHvK.pgp
Description: PGP signature