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

Re: [XaraXtreme-dev] Printing on Linux

So the above several paragraphs should maybe be passed on to the wx
people. Please feel free to do that, anyone.

Thanks for that.

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.

We only have ourselves to blame here. Don't tell anyone, but we use
XOR for more stuff than we should with blobs (i.e. the rendered
on top stuff).

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.

Mart Raudsepp <leio@xxxxxxxxxxxx> - seems to be off air at the

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.

Sure. Having spent enough time looking at (compiled in) filters
and render regions today that my CLs have given up, I really
strongly suggest you look at the XarLib stuff first. Currently
(i.e. as of this moment) no native vector filters work in LX. I
would of course be glad of the assistance debugging and porting
them, but right now the easiest way to get vector filters working
really is the XarLib stuff I gave you a link to. Not that I would
complain about any assistance on the kernel code :-)

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

Ah yes. That is of course true.

So you may eventually want a custom, tree-walking SVG export

Well, we'd planned to do SVG with the filter plugin technology.

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


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.

Spent too long stating at filters today probably.

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

I'd sort of taken it that if there was an in memory format (assuming
it's stream like) we could use the SVG/PDF/whatever reader, and use
that to import. As per the filters doc, our i/f is pretty symmetric
this way.

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

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.

It should be pretty easy to prototype this. If it's not easy, we'd
be very grateful to know why early on :-)