After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 340440 - Doesn't render images created with OpenOffice.org Draw
Doesn't render images created with OpenOffice.org Draw
Status: RESOLVED FIXED
Product: librsvg
Classification: Core
Component: general
2.14.x
Other Linux
: Low normal
: ---
Assigned To: librsvg maintainers
librsvg maintainers
Depends on:
Blocks:
 
 
Reported: 2006-05-02 19:54 UTC by Sebastien Bacher
Modified: 2008-02-24 14:59 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
the SVG (77.62 KB, image/svg-xml)
2006-05-02 20:37 UTC, Dominic Lachowicz
Details

Description Sebastien Bacher 2006-05-02 19:54:32 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?
Comment 1 Vytas 2006-05-02 20:28:23 UTC
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).
Comment 2 Dominic Lachowicz 2006-05-02 20:36:31 UTC
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.
Comment 3 Dominic Lachowicz 2006-05-02 20:37:03 UTC
Created attachment 64689 [details]
the SVG

Attaching the SVG just in case it gets lost or something...
Comment 4 Dominic Lachowicz 2006-05-02 21:17:43 UTC
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
Comment 5 Sebastien Bacher 2006-05-07 22:25:17 UTC
I've opened bug #340963 on eog, if the librsvg part of the issue is fixed that bug can be closed
Comment 6 Dominic Lachowicz 2006-10-27 15:33:24 UTC
Decreasing priority.
Comment 7 Dominic Lachowicz 2008-02-24 14:59:11 UTC
Closing, since 340963 exists.