Comment 46 for bug 511312

I think the most important feature here (from the user-perspective) is to be
able to insert, scale and render SVG images in OOo documents.

This is _not_ the same as being able to convert to OO-Draw's internal vector
format for editing, although this would be the best approach long-term (with
appropriate improvements in OO-Draws GDI engine).

I.e. Why not treat SVG as "just another non-editable image format" and use an
existing SVG-rendering library to render the image as required (like you'd do
with PNG, JPEG etc.). Thus, where OOo would rescale a PNG image to the required
display resolution, it would simply re-render a SVG image to the required
size/resolution.

I'm not sure what the best svg-rendering library would be, however; librsvg has
*nix/Gnome dependencies, ksvg requires libart (a KDE library AFAIK). Batik might
be a good option: written in java it fits OOo's Java-centric world, liberal
apache-style license, *full* W3C standard SVG support. Could it be handled as a
java plugin/extension?

Using a 3rd-party render would have the added benefit of much improved
rendering-quality. As much as I love OO-Draw, OOo's GDI rendering system sucks
(no anti-aliasing, jagged curves...).

Users have many many options for creating/editing SVG images (OO-Draw,
inkscape/sodipodi, sketch, Illustrator etc. etc.) but very few applications can
render them. SVG-rendering in OOo as a feature is a real 1-up on MS-Office.

Finally, I don't agree that a SVG importer must work with *all* SVG flavors to
be useful. All SVG flavors share a common subset of elements and these are the
"most useful" elements for illustrations/line-art. Partial SVG support early is
better than no SVG support until much later.