bugGNU Octave - Bugs: bug #58717, Inputting Chinese Characters and...

 
 

bug #58717: Inputting Chinese Characters and Resizing windows will cause a mess

Submitter:  None
Submitted:  Tue 07 Jul 2020 02:19:01 AM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  None
Originator Name:  Billchenchina Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 5.2.0
Operating System:  * Microsoft Windows Fixed Release:  8.1.0
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 14 Dec 2022 01:02:43 PM UTC, comment #9: 

Oops. I copied the wrong bug number. The report about duplicate full width characters is bug #58637.

Markus Mützel <mmuetzel>
Group administrator
Wed 14 Dec 2022 12:24:58 PM UTC, comment #8: 

Pasting the Chinese characters from comment #0 in the command window now works correctly. That might have been a (positive) side effect of the following change:
https://hg.octave.org/mxe-octave/rev/7c302266a10b

Full width characters are still duplicated though.

Since the latter is already tracked in bug #58717, I'm going to close this as fixed.


Markus Mützel <mmuetzel>
Group administrator
Thu 08 Dec 2022 02:13:16 PM UTC, comment #7: 

With a current nightly build, pasting the Chinese characters (or any non-ASCII characters) into the command window still doesn't work.
However, "F9"-ing them from the editor kind of works now. The characters appear in the command window and are assigned correctly to the variable. Resizing the window still works for me after that (on Windows 11).

Additionally, there is still bug #58717 that causes full-width characters to be displayed twice in the command window.

Markus Mützel <mmuetzel>
Group administrator
Fri 30 Oct 2020 07:48:13 AM UTC, comment #6: 

@Mohamed: What you are reporting are probably bug #47571 and bug #55689 (maybe bug #43099 and bug #50409). The report here is about issues while resizing the command window.

But I agree that it is hard to draw a line between all of these bugs. The solution is probably the same (maybe apart from bug #50409): A complete re-write of the way we are accessing the terminal. (Probably by replacing the command window with a cross-platform Qt text widget, which is a very large project.)

Markus Mützel <mmuetzel>
Group administrator
Fri 30 Oct 2020 02:13:57 AM UTC, comment #5: 

I confirm the problem is only on windows and with Arabic language as well, you cannot input any characters and if you output them from help or code it shows weird characters. the issue is only in the command window from GUI or CLI. The editor renders text well if you set the font to a compatible one in preferences > editor. I am using version 5.2.0-1 which is currently the latest.

Mohamed Farahat <farahats9>
Thu 16 Jul 2020 06:56:46 AM UTC, comment #4: 

@Kai: I wouldn't consider your approach a hack. The used font must provide glyphs for all used characters. Otherwise, they cannot be rendered.

Markus Mützel <mmuetzel>
Group administrator
Thu 16 Jul 2020 06:38:41 AM UTC, comment #3: 

If you are using the "qt" toolkit, there is a little "hackaround":


x = -10:.2:10;
y = sin (x);
plot (x, y);
title ("你好", "FontName", "IPAGothic");


This must be run from a script or function, as the terminal is sometimes reluctant to accept non-ASCII characters.  You can of course choose any other installed font "IPAGothic" supporting Chinese characters.

The "FontName" attribute can be set for many plotting widgets.

Kai Torben Ohlhus <siko1056>
Group Member
Thu 16 Jul 2020 05:51:41 AM UTC, comment #2: 

By the way, is there any solution for CJK text render? Octave is returning these warning when rendering Chinese String 你好

warning: text_renderer: skipping missing glyph for character '6d63'
warning: text_renderer: skipping missing glyph for character '72b2'
warning: text_renderer: skipping missing glyph for character '30bd'

Thanks!

Tianyu Chen <billchenchina>
Tue 07 Jul 2020 08:24:37 AM UTC, comment #1: 

There are a few similar open bug reports: e.g. bug #58637, bug #47571.
Also there is bug #56224. Maybe something similar is happening here. One byte of the (UTF-8 encoded) character might be interpreted as a command that completely breaks the input. (At least this is what I guess is happening.)

We are using the Windows console behind the scenes to provide the command window widget on Windows. Unfortunately, the Windows console has problems handling UTF-8 (or any Unicode fwiw).
I've read somewhere that MS is considering the console to be legacy code (can't find the source at the moment). So there is probably little hope that they are going to invest much effort to improve that situation.

One thing that Octave might be able to do is to write our own (cross-platform) widget for the command window. However, that is a major project (and development in that direction seems to have stalled).
The current implementation works good enough on non-Windows platforms (which use a different model that doesn't work on Windows). Most active developers use Linux...

I guess what I wanted to say is: I can confirm that on Windows the command window doesn't work correctly for international characters. But unfortunately I don't know of a quick fix that would fix all the problems.

IIRC, we are using file handles to communicate with the console. Maybe if we wrote a wrapper that forwarded those streams to the Windows console API (ReadConsoleW and WriteConsoleW), some of the issues would be alleviated.
But all time and effort invested in this now might be in vain if we switched to a cross-platform widget in the future...

Markus Mützel <mmuetzel>
Group administrator
Tue 07 Jul 2020 02:19:01 AM UTC, original submission:  

Hi, I'm a Chinese user and I'm using GNU Octave 5.2.0. When I tried to input any Chinese character into GUI(Whether inputting as a string or comment), Octave doesn't work at all.

For example, I tried to input `s = "你好";`, the command prompt doesn't respond. When I tried to resize the window then, it turned up to a mess(See Screenshot below)

The CLI doesn't work as well.

------

I'll try in Debian to see if this bug exists later.

Anonymous

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #49444:  Octave_GUI_2020-07-07_10-16-56.png added by None (59KiB - image/png)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by farahats9 (Posted a comment)
  • -email is unavailable- added by siko1056 (Posted a comment)
  • -email is unavailable- added by billchenchina (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by None (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 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-12-14 mmuetzel StatusConfirmed Fixed
        Open/ClosedOpen Closed
        Fixed ReleaseNone 8.1.0
    2020-09-01 siko1056 Dependencies- bugs #58834 is dependent
    2020-07-07 mmuetzel StatusNone Confirmed
    2020-07-07 None Attached File- Added Octave_GUI_2020-07-07_10-16-56.png, #49444

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code