GNOME Bugzilla – Bug 172581
gimpdata object filename problem if not representable in file name encoding
Last modified: 2008-01-15 12:51:26 UTC
Run GIMP 2.2 with GLib 2.4 on Win32 in a locale that uses characters that aren't representable in the system codepage (for instance, run GIMP in Turkish on a Western European (codepage 1252) Windows installation). When you quit, it crashes in gimp_data_create_filename() because g_filename_from_utf8() returns NULL because the object names are localized, and some of the localized names contain characters not in codepage 1252. Possible ways to fix this: Maybe gimpobject could also keep a non-localized name for the object to be used for file names? That's probably a too big change for the stable branch, though. Maybe gimp_data_create_filename() should use some fallback name (hex encoded UTF-8?) if g_filename_from_utf8() returns NULL? This problem probably can occur also on Unix, if you have a non-UTF-8 locale but still run GIMP with a LANG setting that uses characters not present in the filename encoding? Or would such a situation come under "don't do that then"?
BTW, running with GLib 2.6 doesn't help either, because GIMP then uses the backward-compatibility version of g_filename_from_utf8() that still tries to convert to the system codepage.
It shouldn't be difficult to handle the NULL return value properly. This can only ever happen for data that should not be saved anyway.
> This can only ever happen for data that should not be saved anyway. OK, good to know. FWIW, in my case, it happened for the gradient called "FG to Transparent"
Fixed in both branches. Also added a warning that should catch similar problems: 2005-04-04 Sven Neumann <sven@gimp.org> * app/core/gimpdata.c (gimp_data_create_filename): return early if called for an internal data object. Fixes bug #172581.
*** Bug 168670 has been marked as a duplicate of this bug. ***