Description of problem: 1) The spec is missing a dependecy on ImageMagick as the office thumbnailer uses convert to create thumbs. 2) Currently convert has several issues when creating thumbs for various fileformats, so HAVE_SETRLIMI should be defined, to keep it from eating many gigs of ram when creating thumbs with leaky software. Ref: http://git.gnome.org/cgit/libgsf/tree/thumbnailer/main.c#n230 Regarding the patch: Is the HAVE_SETRLIMI definition at the right place?
Created attachment 359922 [details] Updated let just libgsf-gnome depend on ImageMagick.
We used to have that, but then it got removed in order to fit it onto a livecd or something. caolanm->mclasen: do we still need to fit this onto a livecd ?
Created attachment 359974 [details] how about this instead, How about we go with gdk-pixbuf as the first attempt to import and scale the thumbnails. That's something I think I intended to do some time ago, that work for you ?
Lets try it that way first given last years "Sep 23 2008" size-problem comment.
The problem occurs to me when creating a thumb for an ODT file, so gdk-pixbuf won't help in that case, but might sort out some other cases. So I'm reopening it.
Why not, I generated a thumb from an .odt as my test-case. Can you attach an example which fails in the new gdk-pixbuf scenario ?
Sorry. I did not test - as I did not see that an other path is taken for zip-files. It works like a charm! Will this be pushed upstream?
Yeah, as http://bugzilla.gnome.org/show_bug.cgi?id=594359 There presumably exist some preview formats embedded in some file formats that might not supported by gdk-pixbuf where the code would still be forced to fall-back to convert, but hopefully that's sufficiently rare to not arise in practice.