[Konsole-devel] [Bug 41744] konsole Shows some Japanese FULLWIDTH chars as HALFWIDTH

[Ken Deeter]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
     
http://bugs.kde.org/show_bug.cgi?id=41744     




------- Additional Comments From ktdeeter at alumni.princeton.edu  2003-11-08 05:49 -------
On further expirementation, it appears that we actually need to look at the locale to figure out what the right wcwidth() function to call is. Here is why:

In EUC-JP, these ambiguous chars are always full width. As such, if a program like bash is running in EUC-JP, when it see the EUC-JP code for such a char, it will always treat it as full width. If konsole mistakenly treats this as a half width char, then the application (such as bash) and the konsole will get out of sync with regards to things like cursor position.

Here is the simple example to show this:

Start up bash using EUC-JP. Enter a ¡û. Konsole currently treats this char as full width. Now hit the left arrow to go back one character. Because bash thinks the ¡û is a full width character, it will actually try to back the cursor up two spaces, but since konsole thinks its only half width, it had only advanced the cursor forward one cell when the character was printed, and when bash tries to move it back by two, it will actually go one too far.

Therefore the correct solution to this problem is as follows: if the locale is one in which these ambiguous chars must be interpreted as double width (which is the case in cjk locales, if my understanding is correct) then we need to use wcwidth_cjk(). Otherwise, we just use wcwidth().

My question is then, would it be useful to have a menu in which one could specify the encoding that konsole uses to convert the output of the program running inside the terminal to unicode. It seems like this might be useful regardless of what we do the problem above, but it would also be easy to solve the problem in the process.