Starting with version 2.58.0, librsvg will no longer use
gdk-pixbuf to decode raster images that are referenced
from SVG documents. For example, an <image> element like this:
<image href="foo.jpg" width="100" height="100"/>
I have just pushed a merge request to make librsvg use the image-rs
crate to decode raster images. This is part of two related changes:
-
Don't load SVG sub-documents with gdk-pixbuf. For historical reasons, librsvg's original C code did not even bother to detect if
<image href="foo.svg"/>referenced another SVG document; it would just ask gdk-pixbuf to render it as for any other image. This works more or less fine in SVG1.1, but for SVG2 we actually have to pay attention to the attributes in the<image>element and the child SVG document, and it's just easier to recurse into librsvg directly. -
Don't load raster images with gdk-pixbuf. Now that Loupe is using the same Rust crates to decode raster images, I think we can begin to move the rest of the platform to not using memory-unsafe codecs.
Librsvg still compiles and installs the gdk-pixbuf loader that lets
other applications render SVG documents as if they were raster images;
nothing is changed there. The C APIs that create GdkPixbuf objects
also remain unchanged.
Testers wanted
As you can imagine, this is the sort of change that gives me a bit of anxiety. Say whatever you want about memory-unsafe code in libpng and libjpeg-turbo, but they are tested and fuzzed all the way to hell, all the time. The Rust crates for decoding images have not been as heavily developed, and there is still plenty of interesting work to do there in terms of performance and support for the more exotic variants of those file formats. I think this is a good opportunity to find exactly what they might be lacking.
Please test the main branch of librsvg, especially if you render
documents which have <image> elements! The changes above are easy
to roll back or to make optional if too much trouble appears.
