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

Re: [XaraXtreme-dev] Printing on Linux

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+

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


Attachment: pgpNDLSFSZRrR.pgp
Description: PGP signature