This PR addresses issue #104 so that supported file types that have incorrect extensions are still opened and displayed.
Files that have no extensions are correctly identified by the function g_file_query_info() which the existing version of xviewer uses. However, if the file name has an extension the function uses the extension to identify the file regardless of the file contents - this is where the problem lies.
The changed code makes up to three attempts to identify the file type.
Firstly the file content is checked against the 'magic numbers' for known image files that support this feature.
If the magic numbers test doesn't identify the file then the function g_content_type_guess() is called.
If the previous two methods have failed to identify the file type the code uses g_file_query_info() + g_file_info_get_content_type().
This code is a modified version of the equivalent section of pix (I trust that this does not infringe any rights).
The table of magic numbers includes the sequence required for webp files in case support for this file type is added in the future.
AVIF files don't have 'magic numbers' and should have a MIME type of image/avif. However, the g_content_type_guess() and g_file_query_info() functions both return strings of application/octet-stream (even if 500 bytes of the file are read). Hopefully the library functions will be updated to recognise AVIF files before support for them is added to xviewer.
SVG files don't have magic numbers but are recognized by the second test noted above provided that a sufficient number of bytes are read from the file. For the scaleable icon file that I was using for test purposes 75 bytes were sufficient but I set the code to read 100 bytes to be on the safe side. The MIME type is then returned as image/svg+xml. If too few bytes are compared the result is application/xml (although xviewer still seems happy with this).
I have tested the following file types with jpg extensions:
png tif gif bmp ico svg webp (webp recognition verified by a temporary statement to display the recognised MIME type)
I also tested a jpg file with a bmp extension
All of the above were correctly recognized based on the contents - verified using a temporary printf statement.
This PR addresses issue #104 so that supported file types that have incorrect extensions are still opened and displayed.
Files that have no extensions are correctly identified by the function g_file_query_info() which the existing version of xviewer uses. However, if the file name has an extension the function uses the extension to identify the file regardless of the file contents - this is where the problem lies.
The changed code makes up to three attempts to identify the file type.
Firstly the file content is checked against the 'magic numbers' for known image files that support this feature.
If the magic numbers test doesn't identify the file then the function g_content_type_guess() is called.
If the previous two methods have failed to identify the file type the code uses g_file_query_info() + g_file_info_get_content_type().
This code is a modified version of the equivalent section of pix (I trust that this does not infringe any rights).
The table of magic numbers includes the sequence required for webp files in case support for this file type is added in the future.
AVIF files don't have 'magic numbers' and should have a MIME type of image/avif. However, the g_content_type_guess() and g_file_query_info() functions both return strings of application/octet-stream (even if 500 bytes of the file are read). Hopefully the library functions will be updated to recognise AVIF files before support for them is added to xviewer.
SVG files don't have magic numbers but are recognized by the second test noted above provided that a sufficient number of bytes are read from the file. For the scaleable icon file that I was using for test purposes 75 bytes were sufficient but I set the code to read 100 bytes to be on the safe side. The MIME type is then returned as image/svg+xml. If too few bytes are compared the result is application/xml (although xviewer still seems happy with this).
I have tested the following file types with jpg extensions:
I also tested a jpg file with a bmp extension
All of the above were correctly recognized based on the contents - verified using a temporary printf statement.