Thu 23 Mar 2017 11:26:31 AM UTC, comment #16:
Closing this bug as duplicate of bug #43099.
|
Mon 26 Dec 2016 07:55:20 AM UTC, comment #15:
On 4.2.0 Japanese characters are represented as expected on windows 10. (I do not have windows 7 PC so I did not test on windows )
This bug is better to be marked duplicated to bug #49386, or bug #43099.
|
Fri 23 Dec 2016 09:50:32 PM UTC, comment #14:
See also bug #49386 (and https://savannah.gnu.org/bugs/?43099#comment34 )
The codepage in the Windows GUI console is now set to 65001 with the Octave 4.2.0 release. It has been reported that international characters are now better displayed in Win10 (but not in Win7).
What is your observation with Japanese characters now?
Should we mark this as duplicate of bug #49386, or bug #43099, or vice versa?
|
Tue 02 Jun 2015 04:33:54 PM UTC, comment #13:
Retagging release from 4.0.0-rc1 to 4.0.0.
|
Fri 08 May 2015 09:02:38 AM UTC, comment #12:
I have tested on mxe-octave that uses gcc-5.1.0. (I thank for Philip!.)
However, the situations are the same as those in 4.x.x and 5.1.0.
This is natural thing because the issue comes from the code page treatment on the windows version of octave.
|
Fri 01 May 2015 12:36:00 AM UTC, comment #11:
I have tested on 4.0.0-rc4.
Two attachment files are for gui mode tests.
After_ls_rc4.png
('ls' causes command windows break)
After_ls_cp65001_rc4.png
The uft8 encode multibyte characters (perhaps also other non-ASCII characters) do not represented correctly.
However, the break of 'command window' does not happen for code page 65001. (system ('chcp 65001')).
I propose the set code page 65001 as default for the command windows of the gui.
For the cli, the code page of console is set to 65001
(file #33850, file #33851)
|
Mon 13 Apr 2015 12:50:11 AM UTC, comment #10:
Cil mode case:
Startup cmd.exe and change font of console to ttf font by Property pane of console.
Execute "chcp 65001 ".
Start cli mode octave e.g. by
C:\octave\Octave-4.0.0-rc3\bin\octave --no-gui
I also attached the snapshot of command console.
(cp65001_command_console.png)
(file #33661)
|
Sun 12 Apr 2015 11:14:30 PM UTC, comment #9:
I have also test Chinese.
The below examples are after "system('chcp 65001')"
See:
Chinese_test_cp65001_rc2.png
Chinese_test_cp65001_rc3.png
Also Chinese situation is worse on rc3.
(file #33659, file #33660)
|
Sun 12 Apr 2015 11:06:00 PM UTC, comment #8:
I have tested on octave-4.0.0-rc3.
on without code page change.
See an attachment file: After_ls_rc3.png
Code page chakge
Some manipulation after that.
See an attachment file : After_ls_cp65001_rc3.png
For utf-8 treatment on windows, results on rc3 are the same those on rc2 and worse than on rc2.
What happens between rc2 and rc3 for codepage treatment on windows binary?
(file #33657, file #33658)
|
Tue 31 Mar 2015 10:59:14 PM UTC, comment #7:
Second execution of 'testing_utf8_jp.m' does not represent anything.
|
Tue 31 Mar 2015 10:46:04 PM UTC, comment #6:
Screenshot is attached: Chinese_test_cp65001.png
(file #33502)
|
Tue 31 Mar 2015 10:42:43 PM UTC, comment #5:
Choosing 中文 font (Chinese font) 'NSimSun' from 'preference',
and after system ('chcp 65001')
Seem to be OK for code page 65001.
|
Tue 31 Mar 2015 10:11:28 AM UTC, comment #4:
Tatsuro, can you also run my testing_utf8.m from #43099?
|
Tue 31 Mar 2015 09:37:23 AM UTC, comment #3:
Sorry inadequate post
However, from octave-gui 4.0.0-rc2, the situation is much improved from that in 4.0.0-rc1.
|
Tue 31 Mar 2015 05:45:55 AM UTC, comment #2:
JohnD Wrote:
> Its probably also related to the lack of utf -8 currently in windows.
Code page 65001 is for utf-8 so that the lack of utf-8 is not correct.
But code page 65001 does not work in many cases.
However, from octave-gui 4.0.0-rc2
|
Mon 30 Mar 2015 10:02:38 AM UTC, comment #1:
For octave-4.0.0-rc2, the situation is changed.
All double byte characters duplicated.
See the attachment file: After_ls_rc2.png
(file #33489)
|
Sat 14 Mar 2015 06:13:52 AM UTC, original submission:
I do not think what I will talk is a bug.
In command window
output window is broken.
However I can see Japanese character is represented.
See an attached file (After_ls.png).
If I change codepage by "chcp" command:
codepage 65001 is for utf8.
See the other attachment fils (After_ls_cp65001.png)
This time the representation of command window in not broken but Japanese character cannot be represented.
The character code in the editor octave-gui seems to be utf-8.
I could handle Japanese character without problem on the Ubuntu using octave-gui of ver. 4.0.0rc1.
However, the command window in windows (win7 I have tested), the codepage is 932 (shift-jis).
Perhaps the problem is caused by codepage of "command prompt" with which windows version octave-gui handles "command window".
I do no have any good idea to treat Japanese Character on windows by octave-gui.
For the moment, I will not use Japanese character in octave-gui in windows.
Tatsuro
|