bugGNU Octave - Bugs: bug #44538, command window problem for windows...

 
 

bug #44538: command window problem for windows for Japanese

Submitter:  Tatsuro MATSUOKA <tmacchant>
Submitted:  Sat 14 Mar 2015 06:13:52 AM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Duplicate Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 4.0.0 Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 23 Mar 2017 11:26:31 AM UTC, comment #16: 

Closing this bug as duplicate of bug #43099.

Markus Mützel <mmuetzel>
Group administrator
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.

Tatsuro MATSUOKA <tmacchant>
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?

Hartmut <hardy>
Tue 02 Jun 2015 04:33:54 PM UTC, comment #13: 

Retagging release from 4.0.0-rc1 to 4.0.0.

John W. Eaton <jwe>
Group administrator
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.

Tatsuro MATSUOKA <tmacchant>
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


>> nihongo
���本語
あいうEnglishあいう
>> system cmd
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

E:\usr\Tatsu\program\Octave\test4.0>type nihongo.m
disp('日本語')
disp('あいうEnglishあいう')
% 日本語のコメント

E:\usr\Tatsu\program\Octave\test4.0>exit
>> nihongo
>>
>> system cmd
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

E:\usr\Tatsu\program\Octave\test4.0>type nihongo.m
disp('日本語')
disp('あいうEnglishあいう')
% 日本語のコメント
E:\usr\Tatsu\program\Octave\test4.0>exit
>>





Tatsuro MATSUOKA <tmacchant>
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


>> system ('type testing_utf8_jp.m')
timesstr = '×'

ellipsize = '…'
lquot = '“'
rquot = '”'

mice_and_rice = 'ネズミと米'
ans = 0
>> testing_utf8_jp
timesstr = ×
ellipsize = …
lquot = “
rquot = ”
mice_and_rice = ネズミと米
>>


I also attached the snapshot of command console.
(cp65001_command_console.png)



Tatsuro MATSUOKA <tmacchant>
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.


Tatsuro MATSUOKA <tmacchant>
Sun 12 Apr 2015 11:06:00 PM UTC, comment #8: 

I have tested on octave-4.0.0-rc3.


ls

on without code page change.

See an attachment file: After_ls_rc3.png

Code page chakge

system ('chcp 65001')


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?


Tatsuro MATSUOKA <tmacchant>
Tue 31 Mar 2015 10:59:14 PM UTC, comment #7: 


>> system('type testing_utf8_jp.m')
timesstr = '×'

ellipsize = '…'
lquot = '“'
rquot = '”'

mice_and_rice = 'ネズミと米'
ans = 0
>> testing_utf8_jp
timesstr = ×
ellipsize = …
lquot = “
rquot = ”
mice_and_rice = ネズミと米
>> testing_utf8_jp
>>


Second execution of 'testing_utf8_jp.m' does not represent anything.

Tatsuro MATSUOKA <tmacchant>
Tue 31 Mar 2015 10:46:04 PM UTC, comment #6: 

Screenshot is attached: Chinese_test_cp65001.png


Tatsuro MATSUOKA <tmacchant>
Tue 31 Mar 2015 10:42:43 PM UTC, comment #5: 

Choosing 中文 font (Chinese font) 'NSimSun' from 'preference',
and after system ('chcp 65001')


>> system('type testing_utf8.m')
timesstr = '×'

ellipsize = '…'
lquot = '“'
rquot = '”'

mice_and_rice = '我爱你 爱着你 就像老鼠爱大米'
ans = 0
>> testing_utf8
timesstr = ×
ellipsize = …
lquot = “
rquot = ”
mice_and_rice = 我爱你 爱着你 就像老鼠爱大米


Seem to be OK for code page 65001.

Tatsuro MATSUOKA <tmacchant>
Tue 31 Mar 2015 10:11:28 AM UTC, comment #4: 

Tatsuro, can you also run my testing_utf8.m from #43099?

Colin Macdonald <cbm>
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.

Tatsuro MATSUOKA <tmacchant>
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


system('chcp 65001')
+verbatim+

After that ls command shows correct view: see attachment file

After_ls_cp65001_rc2.png

Comparing the result of rc1 (see: After_ls_cp65001.png),
it is obviously improved.

And system('type nihogo.m') can type 日本語(Japanese) correctly.

But
>> nihongo

Nothing appears.



(file #33497)

Tatsuro MATSUOKA <tmacchant>
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


Tatsuro MATSUOKA <tmacchant>
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


>> ls


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:


>> system('chcp 65001')


codepage 65001 is for utf8.


>> ls


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

Tatsuro MATSUOKA <tmacchant>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #33850:  After_ls_rc4.png added by tmacchant (90KiB - image/png)
file #33657:  After_ls_rc3.png added by tmacchant (102KiB - image/png)
file #33489:  After_ls_rc2.png added by tmacchant (98KiB - image/png)
file #33338:  After_ls.png added by tmacchant (97KiB - image/png)
file #33339:  After_ls_cp65001.png added by tmacchant (91KiB - image/png)

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by hardy (Posted a comment)
  • -email is unavailable- added by tiagoma
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by cbm (Posted a comment)
  • -email is unavailable- added by tmacchant (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 17 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-03-23 mmuetzel StatusNone Duplicate
        Open/ClosedOpen Closed
        Dependencies- Depends on bugs #43099
    2016-08-04 tiagoma Carbon-Copy- Added tiagoma
    2015-06-02 jwe Release4.0.0-rc1 4.0.0
    2015-05-01 tmacchant Attached File- Added After_ls_rc4.png, #33850
        Attached File- Added After_ls_cp65001_rc4.png, #33851
    2015-04-13 tmacchant Attached File- Added cp65001_command_console.png, #33661
    2015-04-12 tmacchant Attached File- Added Chinese_test_cp65001_rc2.png, #33659
        Attached File- Added Chinese_test_cp65001_rc3.png, #33660
    2015-04-12 tmacchant Attached File- Added After_ls_rc3.png, #33657
        Attached File- Added After_ls_cp65001_rc3.png, #33658
    2015-03-31 tmacchant Attached File- Added Chinese_test_cp65001.png, #33502
    2015-03-31 tmacchant Attached File- Added After_ls_cp65001_rc2.png, #33497
    2015-03-30 tmacchant Attached File- Added After_ls_rc2.png, #33489
    2015-03-14 tmacchant Attached File- Added After_ls.png, #33338
        Attached File- Added After_ls_cp65001.png, #33339

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code