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

Re: [XaraXtreme-dev] Printing on Linux

Carl,

Carl Worth wrote:

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


Well not especially. There are really two points:

1. We pass around DC's. These are currently wxDCs but it turns out
   this is completely broken for the filter system because there
   is no underlying DC. I'm just fixing that (non-trivial patch)
   and reverting to the previous position where there is in essence
   a kernel type.

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. However, the wx interface is relatively limited. We
   also print through OSRenderRegion or derivatives thereof
   sometimes. We could use Cairo via GTK (see above) but that
   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).

So we aren't really using wx APIs for rendering per se. It's just
that OSRenderRegion (i.e. the current non-postscript mode
stuff) uses them. It incidentally fills in bits it can't do
through GRenderRegion (e.g. to do transparency) and then
plots a bitmap.


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.


Perhaps I'm looking at the wrong stuff here. I'm using Dapper here,
and things like gedit 2.14.3 appear to have libgnomeprintui print
dialogs (which look pretty good to me). And my system at least claims
to support PPD files. Also, as I understand it there is nothing to
stop us sending raw PS through now, is there?

> 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

Note I'm not opposed to using GTK+ stuff. It's just that I can't
immediately see how we /could/ use it without static linking in
a custom built wx (we need that for dialogs) modified to work with
it, static linking in a new GTK+, etc. etc. as AFAIK all this is
currently not shipping. Is that right?

Also note that I'm not putting any (personal) effort into
libgnomeprintui (which is the only bit I propose to use). It's
just what wx's print dialog uses by default. If you don't
use that, it uses what appears to be some even older interface!


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.


Mart said he had (briefly) which is why I pinged him. I think
he's at GUADEC if you are.


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:


Yes indeed it's a possibility. I'm not sure what are the prerequisites
though


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.


Camelot -> Filtersystem -> Cairo OR
Camelot -> CairoRenderRegion -> Cairo

seem like the most logical to me.


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.


Oh I'm sure.


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

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.


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).
So, for instance, PDF or (if I understand correctly) SVG.

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


Ah. I should explain in greater detail.

Camelot has a filter system and a rendering system which are perhaps
the most complicated parts of the application. Let's concentrate
for a minute on the filter system. What Camelot does by default
is enumerate a list of native filters. These can work several
ways, including by bitmap generation (nice and easy - uses
internal rendering), by rendering (each filter has its own
derived renderregion class and the normal rendering engine
draws the objects in the standard painter's algorithm way),
or by a tree based export (i.e. by going through all the objects
in memory). One of the issues with this is it makes it hard for
people to add new filters, and can generate a bit of an O(n^2)
problem when people add new object types, fill types etc.

So what we decided to do for new vector filters is to define a
capability based plugin API. The filter runs as separate process
linked to a library we provide. Each filter can identify which
things it can handle, and which it would like the library to
do for it ("I'd like my gradfills rasterized" etc.). The easiest
way to get filters going (we hope) is via this API.

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

Alex