GNOME Bugzilla – Bug 481373
Double clicking doesn't work for files with arbitrary characters in name
Last modified: 2008-10-30 19:59:19 UTC
PROBLEM nr. 1: GIMP cannot open files that contain unicode charaters in their paths when called by an external application (like Windows Explorer). Steps to reproduce: 1. Create a file with a name "тестテスト.jpg" or place any of your image files in a folder named "тестテスト". 2. Double click on the file or (if GIMP is not your default application) right click on it and choose "Edit with the GIMP" from the contextual menu. What you get is an error message: JPEG image Message Could not open <lots of ???.jpg> for reading: invalid argument. GIMP Message Opening <lots of ???.jpg> failed: JPEG image plug-in could not open image. PROBLEM nr. 2: You can still open the file in GIMP internally or by dragging and dropping it. The image processing window displays the filename as question marks (??????.jpg) instead of the correct name (тестテスト.jpg).
That would be a problem with gimp-win-remote. Please report it to the author of that tool. We don't maintain the code for it.
What about the second problem? Is gimp-win-remote responsible for it too?
There's by definition only one problem per bug report. But in this case, I'd say that this is either a problem of your desktop font, the Win32 window manager or a shortcoming of the Win32 backend of GTK+.
I experimented a little bit and can assure you GIMP makes a conversion to ASCII when it has to display the filename on the top of the image editor window. How do I know that? Create a file with the name "αδφąžį.jpg". Open this file with GIMP. The editor window will show you just opened: - file "adfaži" if your system locale is set to Western European; - file "αδφazi" if your locale is set to Greek; - file "???azi" if your locale is set to Russian; - file "???ąžį" if your locale is set to Baltic. So do I open a new bug or is there something from my part I have to do to correct this?
The first problem is both in gimp-win-remote and gimp, and there unfortunately isn't much that can be done about it. The GOption code that GIMP uses to parse the argument vector assumes that on Windows the argument vector is like the argv passed to main(), i.e. it is in the system codepage encoding. The system codepage cannot contain arbirtary Unicode characters. One possibility would be to add a Windows-specific version of g_option_context_parse(), for instance called g_option_win32_context_parse_utf8(), to GLib that could know the argument vector is in UTF-8, and then in GIMP fetch the wide character command line with GetCommandLineW(), then call CommandLineToArgvW() to split it into a wide character argument vector, then convert that into a UTF-8 argument vector, which would be passed to to g_option_win32_context_parse_utf8(). As for the second problem, in GTK+ earlier than 2.12, only characters in the system codepage could appear in window titles. In GTK+ 2.12 any characters can be used in window titles.
it is Windows itself that converts alpha to 'a' when displaying the title bar if the API used for the message pump is the ANSI one, even if one calls SetWindowTitleW(). One has to use the wide char API also for the message pump for the title bar to accept arbitrary characters. (Or something like that, I don't recall the exact details.)
Yes, I remembered correctly, see bug #321597.
Changing the "Unicode" in the Summary to "arbitrary". All characters are Unicode characters. The poiunt here is that those that don't work are arbitrary ones, those that do work are those that are in the system codepage.