On Mon, 12 Jun 2006 21:46:56 +0100, Alex Bligh wrote: > > 2. (far more significant). We plot using RenderRegions - these > encode Camelot's graphics primatives. There are (at present) > two main types of RenderRegion (i.e. classes are derived from > either one or the other) concerned with normal rendering. They > are OSRenderRegion and GRenderRegion. GRenderRegion interfaces > to GDraw/CDraw and uses that for its graphics primatives. > OSRenderRegion uses wx for its graphics primatives. We'd want > to keep this (I think) because it's used for rendering stuff > like dialogs too, whatever. Now what OSRenderRegion does is > call wx, which in turn calls GTK, which in turn might call > Cairo. As for this last bit, (GTK+ might call cairo), in most cases it doesn't, or at least it doesn't get to the interesting parts of cairo. The old GTK+ drawing interface (named GDK) is an old-fashioned drawing interface originally modeled after the xlib drawing primitives. So it provides only integer-pixel coordinates for drawing, non-antialiased rendering, and no splines (as far as I know). When GTK+ started depending on cairo, it was decided not to change these interfaces to start drawing something different than they always had, (for example, to start drawing antialiased lines). Instead, GTK+ just provides support for applications to directly use cairo's API to draw, (that is GDK provides a function that returns a cairo context bound to the widget of interest). This way all of cairo's fancy features, (floating-point sub-pixel positions for all coordinates, antialiased rendering, splines, gradients, etc.), were made available to users of GTK+ without replicating the cairo API in GTK+. So if one were to consider wx integration of cairo, the same analysis might hold, (that it would be better to just provide direct support for getting a cairo context for a wxWidget and drawing with that). This would work particularly well if cairo's multi-platform support provides good coverage for the targets supported by wx. Alternately, maybe it would make sense for the wx code to be ported from using GDK drawing function to start using cairo to draw stuff when targeting GTK+. So the above several paragraphs should maybe be passed on to the wx people. Please feel free to do that, anyone. In the meantime, something like this would benefit Xara. One of the first things I noticed when running Xara LX is that the design is rendered quite beautifully, but the other UI bits, (such as the dashed outline around selections), are rather jarring in their non-antialiased ugliness. > would mean widening the wx interface. Alternatively, we could > just construct a CairoRenderRegion instead. That would allow > us to (for instance) render on screen (assuming there's some > final bit used to get it to screen). Yes, just doing a CairoRenderRegion is a much better plan than trying to shove the stuff you want to draw/print through old wx/GTK+ interfaces. > > 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. > > Mart said he had (briefly) which is why I pinged him. I think > he's at GUADEC if you are. Yes, I'll be there. > Camelot -> Filtersystem -> Cairo OR > Camelot -> CairoRenderRegion -> Cairo > > seem like the most logical to me. OK. As soon as I find the right Saturday, I'll try to make sense of those two options and ask what questions I need to. > OK. Does Cairo have a functional SVG backend? IE can I write to > Cairo and get an SVG file out just like I can get a PDF or > Postscript out? > > If so, that would make xara to cairo at the filter level very > interesting indeed. Yes. It's first available in the 1.1.x snapshots so it will appear in the very-soon-to-appear-and-ship cairo 1.2 release. It should be functional in terms of producing an SVG file that renders faithfully what you handed to cairo. But it may not be the best long-term thing for getting SVG output out of Xara. For example, if people are trying to export SVG from Xara in order to import into inkscape, say, then they're going to want to preserve groups, layers, and objects such as circles as circles, (rather than multiple Bézier splines as will currently come out of cairo's SVG backend). So you may eventually want a custom, tree-walking SVG export filter. But at least being able to get SVG output of _some_ kind out of Xara very quickly via cairo might still be interesting. This is probably quite different than the case of PDF where I think cairo is viable as a long-term export strategy for 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). > > > > I'm not sure what you mean by "cairo files" since no such thing > > exists, (cairo is just a library interface). > > Sorry, that was short hand for "files cairo reads/writes" (I > rather thought you had a metafile format but perhaps I'm wrong). Ah, OK. So "write cairo files" makes sense in that context. It was the reading that threw me off I guess. That doesn't exist in "cairo" but there are what might be considered "companion" libraries that can call into cairo after parsing PDF (poppler) or SVG (librsvg). We're still missing a library for parsing PostScript and calling cairo, (presumably someone could write a ghostscript device to do that, but it doesn't exist yet). Within cairo, we do have a sort of metafile format, but it's currently just an in-memory thing with no on-disk representation. > > And what do you mean by > > "without actually patching the app" ? > > Ah. I should explain in greater detail. ... > There's a bit more about it here: > http://www.xaraxtreme.org/developers/documentation/the_xaralx_plugin_filter_mechanism.html > > As you can see, whether or not it's the final way we'd want to use > Cairo, it's certainly good for rapid prototyping... Yes. Thanks for the explanation. -Carl
Attachment:
pgpNDLSFSZRrR.pgp
Description: PGP signature