Created attachment 22356 [details] File testing mime-type detection. Platform: Arch Linux 2.6.28-1 i686, up-to-date on all packages. PNM-family image files have their filetype reported as application/octet-stream by g_content_type_guess() unless the filename is passed. Steps to reproduce: 1. Copy a .ppm image "test.ppm" into the current directory. 2. Compile and run the attached program (giotest.c), which uses g_content_type_guess() to identify the image from file and from the input buffer. Expected results: Both versions report the mimetype image/x-portable-pixmap. Actual results: From buffer, the mimetype is reported as application/octet-stream (without certainty). This bug affects the ability of new versions of gtk+ to load files. Specifically, gdk_pixmap_new_from_file() fails to load such images entirely and Xournal cannot open .pdf files for annotation as a result.
I'd need the ppm file to be able to see whether it's a problem or not.
Created attachment 22378 [details] .ppm image to test, randomly found on the net Image that reproduces the behavior on my machine. I have also tested a large number of files produced by pdftoppm, but these tend to be ~6 megs and are too large to attach.
$ echo "P6" > foo ; echo >> foo $ file foo foo: Netpbm PPM "rawbits" image data This is a problem with the format itself, where the magic just isn't long enough to improve the magic. A magic number with 2 characters? http://netpbm.sourceforge.net/doc/ppm.html gtk+ shouldn't use shared-mime-info to discover PPM/PBM/etc. image types, the magic just isn't good enough.
* tests/list: * tests/test2.ppm: Add test case for PPM with non-working magic (Closes: #19811) (Note that adding a comment will allow the files to load, if that's any help).
All right. I'll try again to get the gdk-pixbuf people to change their logic. Thanks.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.