Bug 5188

Created attachment 3935 [details] [review]
SVG backend patch

From: Carl Worth <cworth@cworth.org>
To: Emmanuel Pacaud <emmanuel.pacaud@univ-poitiers.fr>
Cc: cairo@cairographics.org
Subject: Re: [cairo] SVG backend patch - update
In-Reply-To: <1123408628.7191.12.camel@localhost.localdomain>
References: <1123408628.7191.12.camel@localhost.localdomain>

On Sun, 07 Aug 2005 11:57:08 +0200, Emmanuel Pacaud wrote:
> Here's attached a more complete SVG backend, along with a cairo-demo
> patch which provides a new cairo_snippets_svg utility.

Hi Emmanuel,

Thanks for continuing your patient effort on this in spite of getting
so little feedback from this. I think we should put this code into CVS
and work on it from there.

I don't know if you've looked at the recent backend interface changes,
(adding the 5 fundamental cairo drawing operations: paint, mask,
stroke, fill, show_glyphs), but I'll think you'll find them quite
interesting. Also, I haven't had time to document things well for a
backend-author's perspective, but the idea is that very little beyond
these five function should be needed in order to create a complete
backend, (assuming the backend can natively support these 5
operations---which the SVG backend should be able to).

> SVG composite and pattern are not implemented.

One thing to think about here may be to implement the SVG backend in
terms of the cairo_meta_surface_t like the PS backend does currently,
and as I intend to make the PDF backend do soon. That may be helpful
for doing more elaborate selection of when to use fallbacks or not for
the SVG output.

> Text support is very rough, since it just draw text as vector
> objects.

It's likely quite hard to do much better. We do plan to support
"selectable text" for PDF output though, which may require additional
public cairo API. That work might also provide some benefit here.

> Patch still depends on libxml.

If I were the one writing this, I wouldn't rely on libxml.

One approach here might be to make a tiny little cairo_xml.c file that
implements a similar interface to the few functions from libxml that
you actually use. Then it would be a rather simple exercise for
someone to remove the libxml dependency (or make it optional) if
desired.

-Carl

Commited.