[cairo] Observations from a newb
cworth at cworth.org
Fri Nov 9 09:54:48 PST 2007
On Fri, 9 Nov 2007 09:56:38 +0100 (CET), Dirk Schönberger wrote:
> I think it would be more useful to try to use external libraries (think
> librsvg for SVG and poppler for PDF), as long as they can be used to
> provide cairo output (without resorting to RGBA buffers). At least for
> librsvg this seems to be the case.
Yes, both librsvg (for SVG input) and poppler (for PDF input) can
target any cairo context, with any kind of target surface.
So you can do svg to pdf or pdf to svg conversions through cairo
already and retain all the vector goodness.
See, for example:
So, no, there's definitely not an impenetrable bubble keeping you from
getting data to cairo, (we just expect you to use other libraries that
specialize in parsing whatever data you're interested in).
PS. I had posted that svg2pdf thing a while back, but the pdf2svg
thing I just pushed out for the first time now. And I couldn't resist
taking a file and running it through both programs several
times. Things did retain their vector goodness, but I never quite got
to a steady state with respect to file sizes:
I haven't looked closely to see what's going on there. There are a few
obvious things that I know though:
* The pdf output benefits from stream compression.
* A big part of the initial size hit on the first cairo-generated SVG
file is more digits than necessary for floating point values, (a
topic of some recent discussion).
* A quick glance at the final SVG file shows *lots* of clipPath
elements, (none of which existed in the original file). Maybe full
page clips over and over again or so?
Anyway, this might be a useful exercise for someone interested in
optimizing the SVG and PDF output from cairo.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20071109/168c7d45/attachment.pgp
More information about the cairo