GNOME Bugzilla – Bug 335391
EXIF data not read when non-English characters are in file path
Last modified: 2008-01-15 14:06:08 UTC
Please describe the problem: If file path contains any non-English (national) characters, the 'save EXIF' option is disabled (grayed) and EXIF is stripped from the file when saving to JPG. If the same file is renamed and its path changed so that it contains only standard characters, EXIF data is saved correctly. Steps to reproduce: 1. Open a JPG image with EXIF data. File name and/or path should contain at least one national character. 2. Try to save the file to JPG. EXIF cannot be saved (the option is disabled). EXIF data is removed from the saved file. 3. Try to save the same file if file path contains only English characters. EXIF is saved. Actual results: EXIF data is removed from the saved file. Expected results: An option to save EXIF data should be available to the user. Does this happen every time? Yes. Other information: Gimp 2.3.7, Windows XP Polish.
What happens if you load from a path that contains only Englisch (ASCII?) characters, but save to one with national characters?
Only original path of the file matters. If I open a file from path that contains national characters, EXIF is not saved, no matter what the save path is. If a file is opened from a path that does not contain national characters, EXIF save option is always available (not grayed), even if save path contains national characters. It seems that EXIF info is not read during file opening if file path contains national characters. Another test. (1) Path without national characters: GIMP prompts "According to the EXIF data, this image is rotated". So EXIF is read. (2) Path *with* national characters: no prompt, image is not rotated (apparently EXIF info was not read at all).
Let's adjust the summary to describe the problem better.
That would most likely be a problem with libexif then. There is probably nothing we can do about this but to ask the libexif maintainers to fix the problem. What version of libexif are you using?
Tested with libexif-10.dll included in GIMP 2.3.7 distribution and with libgimp-12.dll downloaded from the web (same effect).
What does the libexif documentation say about filename encodings?
OK, I had a look at the plug-in and the libexif sources. The problem is that we use exif_data_new_from_file() with a filename that GLib has converted to filesystem encoding for us. With newer versions of GLib the filesystem encoding on Win32 is always UTF-8. Thus g_fopen() must be used. But of course libexif uses fopen() and thus reading the file fails for filenames that contain non-ASCII characters. This can be fixed by using exif_data_new_from_data() instead of exif_data_new_from_file(). We should probably use GMappedFile for this and check if we can use the mmapped file for libjpeg as well.
I've checked in a fix. This could perhaps be improved as indicated in my last comment (reuse the mmaped file for reading the JPEG data), but it should fix the problem for now: 2006-03-28 Sven Neumann <sven@gimp.org> * plug-ins/jpeg/jpeg-exif.c * plug-ins/jpeg/jpeg-load.c * plug-ins/jpeg/jpeg.h: added a utility function to work around filename encoding problems when reading EXIF data (bug #335391).