GNOME Bugzilla – Bug 655406
Nautilus doesn't generate thumbnails for SVGZ images
Last modified: 2012-08-24 22:52:53 UTC
Originally I reported it as bug #655377. Nautilus doesn't generate thumbnails for SVGZ images, while it does for SVG images. I consider it a bug since SVGZ is part of the SVG specification.
I pushed a patch to master which should help with this. Can you please test again with latest git master?
Sorry for the delay. I tested it today with latest nautilus git (7f58050) and it still doesn't preview svgz files for me. I have librsvg 2.34.0.
Created attachment 221206 [details] svgz example Here's an example file from openstreetmap. Can confirm it doesn't preview. Also doesn't seem to load in Sushi but does in eog.
(In reply to comment #3) > Also doesn't seem to load in Sushi but does in eog. Then please file a separate bug report against sushi.
Ok, so what is happening here is this: * Nautilus is calling: gnome_desktop_thumbnail_factory_generate_thumbnail(). * Which handles the thumbnail internally using: _gdk_pixbuf_new_from_uri_at_scale() * Which opens the uri as stream in order to handle remote uris (since gdk-pixbuf only handles files) * This stream is then read from and the data is passed to gdk_pixbuf_loader_write * gdk_pixbuf_loader_write tries to figure out what kind of image file the data is * It thinks it is application/gzip The problem is that by passing in only data and not the filename we lose important metadata that can help determine the mime type. I think one option is try to detect the mime type ourselves and construct a pixbuf loader for that type explicitly instead of hoping the loader will figure it out for us.
Created attachment 221311 [details] [review] Determine the correct mime type when we still know the filename
Review of attachment 221311 [details] [review]: This patch could use a concrete example of a case that broke. Something like "When encountering .png files, we know they're PNG"? Or something? ::: libgnome-desktop/gnome-desktop-thumbnail.c @@ +314,3 @@ + the image type. */ + filename = g_file_get_basename (file); + mime_type = g_content_type_guess (filename, data, sizeof (data), NULL); sizeof (data) is wrong here. You need to pass down the length.
Created attachment 221330 [details] [review] Determine the correct mime type when we still know the filename This fixes the case where we want to load .svgz files. If we just sniff the data we'll determine that they are application/gzip. This passes down the read data and fixes a crash where gs_read_file fails but doesn't set an error (which seems like bad practice).
Review of attachment 221330 [details] [review]: Just style things, feel free to commit or fix as you wish. ::: libgnome-desktop/gnome-desktop-thumbnail.c @@ +350,3 @@ GFileInfo *file_info; GInputStream *input_stream; + GError *error = NULL; I think this whole function would be a lot cleaner if we changed it to "throw" i.e. have a GError, and propagate back up to the caller. But up to you. @@ +415,3 @@ + if (loader == NULL) { + loader = create_loader (file, buffer, bytes_read); + if (1 <= width || 1 <= height) { Weird. I'd usually write: width > 0 || height > 0
Review of attachment 221330 [details] [review]: Thanks for the review. ::: libgnome-desktop/gnome-desktop-thumbnail.c @@ +350,3 @@ GFileInfo *file_info; GInputStream *input_stream; + GError *error = NULL; Agreed, but I was just going to least change. @@ +415,3 @@ + if (loader == NULL) { + loader = create_loader (file, buffer, bytes_read); + if (1 <= width || 1 <= height) { Agreed, that is just moved code and not new.
Attachment 221330 [details] pushed as 6c4d2ac - Determine the correct mime type when we still know the filename
Thanks. :)
Don't thank us too much. You are very likely still out of luck because SVGZ images are more likely to trigger deadlocks because the svg loader is not threadsafe :(