[cairo] SVG backend status

[Emmanuel Pacaud]

Hi,

Since it seems it's status week, here's the current status of SVG
backend on master branch.

1) Test suite

SVG backend fails on 20 tests over 68, but as you'll se below, it's not
that bad.

composite-integer-translate-over
paint-with-alpha
scale-source-surface-paint

These tests fail because of an issue when rendering SVG to png, where
painted images have an offset of 0.5 pixel. Not sure if it's a librsvg
issue or a cairo one:  http://bugzilla.gnome.org/show_bug.cgi?id=330055

linear-gradient
set-source
trap-clip

They fail because of a one digit error of color value on some area of
converted SVG file. Here also, I'm not sure who to blame.

text-antialias-none
text-antialias-subpixel
unantialiased-shapes

Unantialiased properties are not really supported by SVG format. We
could try to use text-rendering, shape-rendering and image-rendering
properties: http://www.w3.org/TR/SVG/painting.html#RenderingProperties
but they will not give us what we really want, and support for these
properties in SVG renderer is seldom.

show-text-current-point
text-antialias-gray
text-pattern

Since texts are stored as path in produced SVG files, they don't match
exactly to reference image when exported to png via librsvg.

unbounded-operator
mask
operator-source
operator-clear
clip-operator

Currently, SVG backend use SVG 1.2 compositing operators, and librsvg
doesn't support them. 

mask-ctm
mask-surface-ctm

I think these test fail because mask by image is not supported in
librsvg, but since I didn't find a renderer supporting this feature, I'm
not sure produced SVG files are correct.

rectangle-rounding-error

I'm not sure why this one fails.

2) Performance issues

  a) Text rendering

Currently, texts are converted to paths, leading to big output files in
case of lot of texts.

I can think of 3 possible solutions:

- the most simple one, and most supported by current renderers: convert
each glyph to path and store them in <defs> section, tracking duplicates
via a hash table.
- another simple way, but apparently not widely supported, would be to
use SVG fonts.
- a more interesting way but trickier would be to try to use <text>
element. It requires some work on pango and on cairo backend interface
in order to have all necessary informations for filling <text>
properties. Only this solution would allow an easy edition of text in
the produced SVG files.

  b) Image compositing

Currently, each time a raster surface is composited onto a SVG surface,
it is embedded as png image, without checking if the same surface was
already embedded. Current backend interface does not provide "revision"
information of a given surface, so there's not an easy way to now if a
surface was already embedded. I guess PDF and PS backend face same
issue.

  c) Libxml

SVG backend uses libxml, building a complete xml tree in memory, before
saving. It's not the most efficient way to proceed, and an improvement
would be to use xmlwriter API of libxml, or even drop libxml dependency
and implement the small subset of xmlwriter needed for our SVG backend.

3) Conclusion

SVG backend is mostly complete now, if we accept the use of SVG 1.2
features. This can be avoided by adding support of analysis-surface and
use raster image fallbacks in order to emulate compositing operators,
and with an API to enable/disable SVG 1.2 features.

SVG files using SVG 1.2 compositing operators and mask are not tested,
because of the lack of support for theses features in librsvg.

Text support is far from ideal, but I guess main use case for this
backend if not page full of text.

Image embedding is not efficient, but not very different from what's
done in PDF and PS backends.

Since I would really love to have a supported SVG backend in next cairo
1.2 release, please tell me what needs to be done to make that happen.

	Emmanuel.