GNOME Bugzilla – Bug 691169
Gimp fails to open files with UTF8 characters as filenames when started via Windows Explorer (e.g. the file context menu)
Last modified: 2014-03-16 22:43:07 UTC
if you open a jpg that the filename is Japanese characters, Gimp will error out with "Opening '<filepath>?????????.jpg' failed. Could Not Open '<filepath>?????????.jpg' for reading: Invalid Argument"
Created attachment 232805 [details] filename with japanese charset
2.6.10 is obsolete, please try this with 2.8.2 and report back.
same error occurs in Gimp 2.8.2
Works fine for me. Does this depend on something else, e.g. the locale of the system?
no I just right click open with 'GNU Image Manipulation Program' and that error occurs EVERY TIME!!! no other program has this issue!!! and ONLY occurs with Gimp... if I rename it to only English letters, it works fine but NOT with Japanese characters...
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. This bug often occurs on opening a file directly from the file manager if the filename has Non-ASCII characters. A workaround to open the file in GIMP until this bug is fixed is to use File/Open or dragging the file from your file manager into the GIMP window. *** This bug has been marked as a duplicate of bug 522131 ***
How is this a duplicate if bug 522131??? there is NOTHING similar regarding these two bugs!!! they are talking about commandline interfaces which I NEVER use!!! this is regarding open with 'GNU Image manipulation' program!!! no commandline ANYTHING here!!! read bug 522131 before you say this is a duplicate bug!!!
Calm down. It is a duplicate. Using !!! and CAPS doesn't help with taking you serious. *** This bug has been marked as a duplicate of bug 522131 ***
how??? there is nothing regarding right-clicking and opening with Gimp in that bug!
When you right click on something and choose to open with gimp, it causes windows to run the gimp with certain command line parameters. This is a duplicate of bug 522131 because the issue is with how the gimp parses those parameters. Please close this.
Glib needs to be extended first (see bug 522131). After that, Gimp itself needs to be adapted to use new api from glib.
*** Bug 691822 has been marked as a duplicate of this bug. ***
Dependency on the glib bug is set, let's keep this as a reminder.
*** Bug 724566 has been marked as a duplicate of this bug. ***
Created attachment 271310 [details] [review] load_localized_files_in_windows_2_8.patch I have a patch for that. The problem is, that int main (int argc, char **argv) just takes a char * as parameter. I think, differing from glibs gchar *, char is not utf-8, but ANSI. The trick now is to make use of the entry point int wmain (int argc, wchar_t **argv) where wchar_t is utf-16 coded. This entry point is choosen, if (with a newer compiler) the linker option -municode is activated. In that entry function, the utf-16 chars are transformed to utf-8 format and the standard main entry is called. When loading the file, the filename must be recoded to a windows readable coding. The patches are for master (..._2_9) and for 2.8 (..._2_8).
Created attachment 271311 [details] [review] load_localized_files_in_windows_2_9.patch
glib recently got functions to deal with this, and I'd prefer to use their solution because it's a bit cleaner. There's an example of using it at the bottom of the description at: https://developer.gnome.org/glib/unstable/glib-Commandline-option-parser.html#glib-Commandline-option-parser.description This is currently only available in glib master, not in any release. It should be in glib 2.40 when that's released. I don't know if it would be okay to bump the glib requirement on 2.8 if the bump only applied for windows platforms. We might want to copy the glib functions into gimp until we can depend on newer glib versions.
We can't depend on 2.40 before it's even released :) Our policy (as in pure policy in order to shut down infinite discussions) is that GIMP master can depend on what is in debian testing. IMO we should simply #if GLLIB_CHECK_VERSION() and use the new stuff, so windows builds can be fixed by simply using newler GLib, in both 2.8 and master. I actually have a patch stashed for that, let me push this to master.
Fixed in master, please somebody test and report back before we merge that to 2-8. commit 774e064fbf4bc81add8d00182ee677175aa23c55 Author: Michael Natterer <mitch@gimp.org> Date: Sat Mar 8 22:38:27 2014 +0100 Bug 691169 - Gimp fails to open files with UTF8 characters as filenames... ...when started via Windows Explorer (e.g. the file context menu) When built against GLib >= 2.39.90, use g_win32_get_command_line() and g_option_context_parse_strv() which handle all sorts of windows filename encodings properly. app/main.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
I've tested mitch's commit, and it works correctly.
Tested and cherry-picked to 2.8. commit 410ea91e226f01dc6723555534cf3650782aeb64 Author: Michael Natterer <mitch@gimp.org> Date: Sat Mar 8 22:38:27 2014 +0100 Bug 691169 - Gimp fails to open files with UTF8 characters as filenames... ...when started via Windows Explorer (e.g. the file context menu) When built against GLib >= 2.39.90, use g_win32_get_command_line() and g_option_context_parse_strv() which handle all sorts of windows filename encodings properly. (cherry picked from commit 774e064fbf4bc81add8d00182ee677175aa23c55)
*** Bug 726480 has been marked as a duplicate of this bug. ***