[cairo] SVG backend patch - update

[Emmanuel Pacaud]

Hi,

Le mardi 06 décembre 2005 à 14:05 -0800, Carl Worth a écrit :
> 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.

Commited. SVG backend is optionnal and disabled by default.

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

I'll look into this.

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

I guess libxml is already present on a lot of system, so it doesn't
really hurt to use it.

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

But I agree with this proposal. My plan is to convert current libxml use
to a use of its simpler and more efficient xmlwriter API, using an
interface in cairo_xml.c.

	Emmanuel.