[cairo] SVG backend status

[Carl Worth]

On Sat, 08 Apr 2006 19:05:49 +0200, Emmanuel Pacaud wrote:
> Since it seems it's status week, here's the current status of SVG
> backend on master branch.

Thanks for the update.

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

Those definitely seem worth a bit of extra investigation.

> text-antialias-none
> text-antialias-subpixel
> unantialiased-shapes
> 
> Unantialiased properties are not really supported by SVG format.

That's something I don't care much at all if it works or not...

> could try to use text-rendering, shape-rendering and image-rendering properties:
> http://www.w3.org/TR/SVG/painting.html#RenderingProperties

It probably makes sense to make an attempt to put the right thing out
into the file, but I certainly won't get worked up if the test suite
SVG->PNG stuff doesn't respect it.

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

So here's a case where you can simply mark the current output as good
and then use it for future checks. The way we do this is the test
suite supports backend-specific reference images. So, for example you
would do something like:

	cp text-pattern-svg-argb32-out.png text-pattern-svg-argb32-ref.png
	cp text-pattern-svg-rgb24-out.png text-pattern-svg-rgb24-ref.png

And the text-pattern test should magically start passing. And then you
can "git add" these new reference images.

You should do that for these three text tests, and I would be fine if
you did it for the antialias-property-testing tests discussed above.

> unbounded-operator
> mask
> operator-source
> operator-clear
> clip-operator
> 
> Currently, SVG backend use SVG 1.2 compositing operators, and librsvg
> doesn't support them. 

That's too bad. Fortunately the librsvg hackers are good and fast, so
hopefully this will be resolved soon.

In the meantime, it's a bit tricky to know what to do. Using the
backend-specific reference images isn't a good idea as we're not
actually validating that the current results are correct. It might
make sense to invent a way for the SVG backend to return UNTESTED for
these cases. Another option would be XFAIL, (but with the current test
rig, XFAIL applies at a coarser per-test rather than per-backend
granularity like UNTESTED does).

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

That's pretty similar to the Type3 stuff we're currently spitting out
in the PostScript backend.

> - another simple way, but apparently not widely supported, would be to
> use SVG fonts.

That's also similar, but obviously less attractive if unsupported in
the renderers.

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

Right. Similarly, we want to make sure we can have selectable text in
the PDF output from cairo, so we might need to solve the same problem
for that.

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

Yes, same issue. For getting all of the meta-surface code efficient
we're going to need to implement some copy-on-write semantics for
surfaces, (so that the meta-surface won't have to copy every surface
used in a source pattern). When we do that, you'll have all the
information you need to emit each source surface a single time.

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

It's always seemed to me that a good approach would be to get
something going quickly with libxml and then when it's mostly complete
(that is, about now), just drop the dependency. It really shouldn't be
that much work, right? For example, the syntax of SVG is a lot simpler
than PDF for example, (with all of its byte-offset cross-references),
but even the PDF stuff we do "manually" in cairo without requiring a
huge amount of code.

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

It sounds like you're right in line with the work we're doing on
PS/PDF.

And some of the work needed for PS/PDF might help SVG as well,
(particularly if the SVG backend switches over to use
paginated/analysis---though I don't know if it really needs to or
should[*]).

So I don't see why this shouldn't go in to 1.2 as well.

The most obvious way it's "behind" PS/PDF is that those backends
already pass the entire test suite, but that's mostly due to:

1) Those backends wimp out and use images for all of the "hard" stuff,
   (SVG could too by switching to paginated)

2) Those backends benefit from more mature/complete rasterization
   tools during out current test suite process.

-Carl

[*] If the SVG backend can avoid using paginated it will be more
speedy, though I'm not sure how important that aspect of this
backend's performance really is in practice.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20060413/547ef3c9/attachment.pgp