GNOME Bugzilla – Bug 642725
EOG does not render SVG elements from other files at 100% zoom.
Last modified: 2011-05-27 17:48:13 UTC
Created attachment 181297 [details] example svg I am forwarding this downstream bug: https://bugs.launchpad.net/ubuntu/+source/eog/+bug/721554 When an SVG 'use' tag links to an element in another file and the zoom is 100%, EOG does not render that element. Change the zoom higher or lower and the element is rendered. Go back to 100% and the element goes away. Also, if a gradient is defined in another file, EOG will not render it at 100% zoom, but will at other zoom values. The attached zip file contains two SVGs, one of which, 'parent.svg', uses elements from the other, 'child.svg'. Both problems are demonstrated. In the file 'parent.svg', a red rectangle with a blue border will appear on the left and a gradient will appear in the rectangle on the right at non-100% zoom values.
Appears to be a working dir problem as it only happens when eog is not started in the folder the files are in (or through nautilus). Just wondering why it doesn't affect the scaled view.
Okay, the problem is that eog still renders the SVG into a raster image representation which is used at 1:1 zoom, for thumbnailing and saving and is shown scaled when filtering is disabled. This is done through librsvg's gdk-pixbuf-loader which unfortunately has no way of setting the base URI for relative paths in the SVG files and thus does not find child.svg for rendering. The solution would be to produce the pixbuf from the RSVG output ourselfs instead of falling back to gdk-pixbuf. Not sure how hard that is right now, as eog's image loading code is quite a beast.
This actually partially fixed in the eog-3.0 development path. The SVG is always rendered using the RSVG data there, so the SVG will display correctly. It's still not saving correctly there as that is still using the fallback raster representation.
commit d57936817e1738aaa6d359de45aeab7a48a280c8 Author: Felix Riemann <> Date: Fri May 27 19:30:01 2011 +0200 Use the result of librsvg's parser to generate pixel data out of SVGs Resolves problems with converting SVGs that use relative paths. Also avoids the duplicate SVG parsing by gdk-pixbuf's SVG loader. It's not the nicest code, but we need to split EogImage in format-specific variants anyway. So, this can stay like this until then. https://bugzilla.gnome.org/show_bug.cgi?id=642725 This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.