Here's attached a patch that adds a SVG backend to cairo. It currently uses libxml for generating SVG xml tree. Glyphs are rendered as paths. It's not yet in a commitable state. I'm awaiting comments for continuing this work. Does this patch looks ok ? Is libxml an acceptable dependancy ? If so, I probably still have to change patch in order to use XmlWriter API. Emmanuel.
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.