[cairo] SVG backend status

[Dominic Lachowicz]

Hi Emmanuel,

Whenever you say "we can't properly test XXX because librsvg doesn't
support XXX", please file a RFE in Gnome's bugzilla and mention that
Cairo 1.2's SVG backend requires the feature. Attach samples and a
pointer to the part of the SVG 1.2 spec that you're using :)

We will try to fix things as quickly as possible on the librsvg HEAD
(2.15.x) branch.

Best,
Dom

On 4/8/06, Emmanuel Pacaud <emmanuel.pacaud at univ-poitiers.fr> wrote:
> 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.
>
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://cairographics.org/cgi-bin/mailman/listinfo/cairo
>


--
Counting bodies like sheep to the rhythm of the war drums.