Mon 05 Sep 2016 12:38:52 AM UTC, comment #13:
I think that this bug has not been fixed yet but duplicated to the bug #42036.
Therefore correct status is duplicated but not fixed.
|
Tue 10 Feb 2015 06:05:35 AM UTC, comment #12:
Yes, the gui can handle unicode characters in file names, but what about octave itself? In the command window (gui and cli) it is not possible to enter special characters and existing directories with special characters are not shown correctly (like in 'pwd' as mentioned by Rik's comment #7).
|
Tue 10 Feb 2015 12:30:12 AM UTC, comment #11:
I believe Qt is Unicode. Looks like the terminal is processing data as Unicode, however we call QTextCodec::setCodecForCStrings (QTextCodec::codecForName ("UTF-8")) in octave-gui.cc, so would be getting multiple bytes for some characters ? which we might not be handling correctly.
|
Mon 09 Feb 2015 09:14:38 PM UTC, comment #10:
Pushed Patch with changeset
http://hg.savannah.gnu.org/hgweb/octave/rev/3db04b75c7c0
|
Mon 09 Feb 2015 09:09:33 PM UTC, comment #9:
I'm adding John D. to the CC list. He seems to have the most experience with MXE and can tell whether we are doing an ANSI or Unicode build of the terminal. Hopefully he can also tell us whether this is an easy thing, or something to forget about unti release 4.2.
|
Mon 09 Feb 2015 08:56:05 PM UTC, comment #8:
Am I right that the mxe build for windows is an ansi, not an unicode build? I guess this is the cause for the remaining oddity (which can be seen in the cli version, too) and also for bug #43099.
|
Mon 09 Feb 2015 04:54:09 PM UTC, comment #7:
@Torsten: Your patch works on Windows 7 so it should be applied and then this bug can be closed.
There remains one oddity. The Terminal in the Command Window is not running Unicode so 'pwd' produces a strange set of symbols for a directory with special characters even though the name displays correctly in the File Browser.
|
Sun 08 Feb 2015 05:41:36 PM UTC, comment #6:
I don't think there's any reason to support XP, it's just the virtual machine I have available for testing. I'll have to borrow another computer with Win 7 to test this.
|
Sun 08 Feb 2015 02:02:18 PM UTC, comment #5:
Does Win XP use Unicode encoding per default? If not, should we still support XP?
|
Tue 03 Feb 2015 09:42:07 PM UTC, comment #4:
The patch doesn't work for me. This is on an old Windows XP OS running in a virtual machine. See the attached screenshot which shows me trying to use the File Browser to descend into a directory with "a umlaut" and "o umlaut" in the name. The name is displayed correctly in the File Browser, but not in the terminal.
(file #32989)
|
Tue 03 Feb 2015 07:14:49 PM UTC, comment #3:
@Torsten: I'm building mxe-octave to test this. I'll let you know in a few hours.
|
Sun 01 Feb 2015 01:43:57 AM UTC, comment #2:
I can't do that right now as I'm to inexperienced; I've never made a build by myself yet.
|
Thu 29 Jan 2015 07:58:50 PM UTC, comment #1:
Thank you for the report. I have attached a patch that solves the issue on my Win 7 system. Are you able to make a patched mxe-build for testing?
(file #32944)
|
Wed 28 Jan 2015 11:43:10 AM UTC, original submission:
I hope this bug report isn't redundant, since I feel it might be related with bug #43099.
If you try to open a folder that contains special characters like ä, ö, ü an error like
is thrown.
Some further observations:
1) You need to STRG+C on the terminal, since the error won't "return" the input to the user.
2) Also, after canceling you will notice that the current directory didn't change but the file browser (i.e. pwd/the current directory and the file browser get out of sync).
3) After the file browser got out of sync (see point 2) you can try to open a file and will get big error message
4) Even the "Change Directory or Add Directory to Load Path" dialog that pops up can't move into such directories (for both cases: either adding the directory to the path or changing the current directory fails).
I only tested this on Windows 7 64-Bit.
|