bugGNU Octave - Bugs: bug #50404, Incorrect line wrap using...

 
 

bug #50404: Incorrect line wrap using characters with double column width in Command Window

Submitted by:  Mingye Wang <arthur2e5>
Submitted on:  Sat 25 Feb 2017 11:47:33 PM UTC  
 
Category: GUISeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: ConfirmedAssigned to: None
Originator Name: Open/Closed: Open
Release: devOperating System: Microsoft Windows

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Tue 11 Apr 2017 01:59:17 PM UTC, comment #7:

Just finished installing the Creators Update (Windows 10 version 1703). Now I am seeing the same problem that you see.
What did MS do???

Markus Mützel <mmuetzel>
Project Member
Wed 05 Apr 2017 08:31:57 AM UTC, comment #6:

Sorry. That took longer for me to understand than it probably should. I never noticed that there are characters that occupy two columns compared to other (e.g. Latin) characters.
Re-worded again. Does it now better describe the issue?

I still cannot reproduce (neither with "Consolas" nor with "Courier New"). Calling "faa" multiple times doesn't mess up the line wrap for me. I am on Windows 10 build 14393 (version 1607, German locale). So that is different to your system.
I don't know what causes the issue for you. Maybe something changed in the Windows console between versions. I will report back when I got version 1704...

Markus Mützel <mmuetzel>
Project Member
Wed 05 Apr 2017 04:43:49 AM UTC, comment #5:

Update: 4.2.1 displays the same problem.

Anonymous
Tue 04 Apr 2017 09:33:24 PM UTC, comment #4:

> Are you OK with that change?


Not quite. The wrapping problem has nothing to do with how many bytes the character take up -- in UTF-8 it's three bytes for most chinese characters, and "real" double-byte stuff like "π" does not mess up the alignment. This is a column counting problem. Referring to wcwidth()'s manpage may help.

> Could you also please try if the same happens on the CLI?


In 4.2.0 conhost seems to handle it just fine. The codepage was not set to 65001 at first, but after some chcp it looks just fine. (You may need to set a CJK-capable font to correctly see it "just fine".)

> But could you please try with the recently released Octave 4.2.1 whether the issue still persists?


Grabbing the installer, will report back soon.

Mingye Wang <arthur2e5>
Tue 28 Feb 2017 02:01:43 PM UTC, comment #3:

I re-worded the title. Are you OK with that change?

I am not aware of any recent bug fixes that could affect that particular issue. But could you please try with the recently released Octave 4.2.1 whether the issue still persists?
Could you also please try if the same happens on the CLI? You might have to set the codepage to UTF-8 first with the following command:

Markus Mützel <mmuetzel>
Project Member
Mon 27 Feb 2017 06:54:15 PM UTC, comment #2:

The "double column character" I referred to means characters that yield a column count of 2 when queried with, e.g. wcwidth(L'著'). The "terminal window" I was talking about refers to the "Command Window" (oops) tab in the GUI. I am running Windows 10 build 15042, if that helps too.

The code should be correct by itself. I have swapped fonts to Consolas and was able to reproduce the bug, so it doesn't appear to have anything to do which my latin+CJK monospace font...

A related thing to test for is zero-width characters like zwsp, but it doesn't appear to cause any troubles on my copy of Octave 4.2.0.

Mingye Wang <arthur2e5>
Sun 26 Feb 2017 03:50:01 PM UTC, comment #1:

I cannot duplicate the problem in Octave 4.2.1 and 4.2.0 on Windows 10.

Saving your example function to "faa.m" and executing it yields the following:

So nothing seems to be wrong here.
I don't know what a "double column character" is. So something might have gone wrong during copy-pasting your example code.
Could you please attach your example code here to make sure, we are trying the same?

Markus Mützel <mmuetzel>
Project Member
Sat 25 Feb 2017 11:47:33 PM UTC, original submission:

Running the following function in Octave 4.2.0 results in a messed-up terminal window:

The terminal alignment appears ruined by the double-column character '著', with the input prompt ">>" shifted to the right side of the screen. Stacking multiple such characters with strings like '世界' causes the ">>" to gradually shift back to the left.

Mingye Wang <arthur2e5>

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #39833:  OctaveAlign.PNG added by arthur2e5 (72KiB - image/png)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -unavailable- added by mmuetzel (Posted a comment)
  • -unavailable- added by arthur2e5 (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 8 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 11 Apr 2017 01:59:50 PM UTCmmuetzelStatusNone=>Confirmed
    Wed 05 Apr 2017 08:33:50 AM UTCmmuetzelDependencies-=>bugs #50284 is dependent
    Wed 05 Apr 2017 08:31:57 AM UTCmmuetzelStatusNeed Info=>None
      Release4.2.0=>dev
      SummaryDouble-byte characters lead to incorrect line wrap in Command Window=>Incorrect line wrap using characters with double column width in Command Window
    Fri 31 Mar 2017 07:35:46 PM UTCmmuetzelStatusNone=>Need Info
    Tue 28 Feb 2017 02:01:43 PM UTCmmuetzelSummaryTerminal Window seems unable to handle multi-column characters=>Double-byte characters lead to incorrect line wrap in Command Window
    Sat 25 Feb 2017 11:47:33 PM UTCarthur2e5Attached File-=>Added OctaveAlign.PNG, #39833

    Back to the top


    Powered by Savane 3.1-cleanup1