GNOME Bugzilla – Bug 340440
Doesn't render images created with OpenOffice.org Draw
Last modified: 2008-02-24 14:59:11 UTC
That bug has been opened on https://launchpad.net/distros/ubuntu/+source/eog/+bug/42629 "EOG crashes on SVG images created with OpenOffice.org Draw. As I understand, the problem is that OpenOffice.org SVG export plugin uses plain huge integer dimensions, not centimeters, inches or something relavant. EOG just fails to allocate memory for an "über"-sized image then. I guess that from the following output: GLib-ERROR **: gmem.c:154: failed to allocate 2412898400 bytes aborting... Program received signal SIGABRT, Aborted. [Switching to Thread -1239532624 (LWP 11914)] 0xffffe410 in __kernel_vsyscall () (gdb) Personally Im not sure which side requires fixing, maybe both. OpeOffice should export in sane dimensions, and EOG should automatically reduce images or do something but not crash. Both Firefox and Inkscape load the image correctly. http://librarian.launchpad.net/2437909/crash.svg Crashes with SIGABRT" rsvg-view has the same issue. Is that an librsvg issue or should the applications try to resize the svg first?
IMHO this is not purely librsvg issue, maybe merely programs' that use librsvg and request huge sizes. For example, if you save the given file, nautilus thumbnails it correctly (using the same librsvg).
So, EOG and rsvg-view will no longer crash on this image. But it isn't rendered properly, either. OO Draw could make our lives easier, granted. But I don't think that they're doing anything illegal, per-se. This image also exposes a SEGV in Cairo via the rsvg-convert program. Updating the title to reflect the work remaining.
Created attachment 64689 [details] the SVG Attaching the SVG just in case it gets lost or something...
I'm not sure how much more librsvg-the-library can do here. rsvg-view the app can certainly use improvement, and I should get around to it in the next few days. When the SVG provides no size (and the size can't be computed by finding the image's bounding box), we have no choice but to assume that the viewbox represents units in user-space. In this case, that's 21590x27940 pixels. We dutifully report the image's width&height in pixels, as well as the X&Y DPIs, as required by the spec. The calling application then has a duty to "sanitize" those values. In EOG's case, that might mean restricting the image's size to the size of the visible window. http://www.w3.org/TR/SVG/coords.html#Introduction
I've opened bug #340963 on eog, if the librsvg part of the issue is fixed that bug can be closed
Decreasing priority.
Closing, since 340963 exists.