[konsole] [Bug 378124] New: Character width for HIGH VOLTAGE SIGN possibly wrong

[Thomas Luzat]

https://bugs.kde.org/show_bug.cgi?id=378124

            Bug ID: 378124
           Summary: Character width for HIGH VOLTAGE SIGN possibly wrong
           Product: konsole
           Version: 16.12.0
          Platform: Debian unstable
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: font
          Assignee: konsole-devel at kde.org
          Reporter: thomas+kdebugs at luzat.com
  Target Milestone: ---

Created attachment 104749
  --> https://bugs.kde.org/attachment.cgi?id=104749&action=edit
Third-party terminal screenshot to show the symbol/prompt

I am using konsole with Source Code Pro font, (oh-my-)zsh and agnoster theme.
This looks similar to attached screenshot, taken from
https://gist.github.com/agnoster/3712874 When becoming root the command prompt
contains Unicode character \u26a1 (HIGH VOLTAGE SIGN). The character is
rendered with a 1 character width. Problems with that character are
reproducible with other shells by just copy & pasting the Unicode character
into some konsole. Two symptoms of the problem are:

1. In the configuration above: When using tab completion (e.g.: enter ab, press
TAB), the prompt doesn't show "ab" but becomes "aab". That is, the completion
is inserted with an offset of one character. Trying to backspace 3 times or
delete the line with C-u only the "ab" gets deleted.

2. Easier to reproduce: Copy & paste the character \u26a1 into some shell
running in konsole. Backspace or C-u make konsole move 2 characters backwards
instead of one, deleting parts of the prompt. Cursor movement across the
character moves too far.

xterm and urxvt on the same system with the same font show different behavior:
They render the symbol as a character which is two cells wide (horizontally
centered within that box). All operations (tab completion, character deletion,
cursor movement, linewrapping, ...) work as expected.

Debian is using glibc 2.24-9 with Unicode 9.0 EastAsianWidth.txt; this means
the glibc wcwidth returns 2 for \u26a1. I do not know if older versions of
glibc (<2.24-6) have shown the same behavior. EastAsianWidth.txt of Unicode 8.0
didn't contain \u26a1; it may be that it started when glibc switched to Unicode
9.0 (which it will on all distributions with 2.26).

I patched konsole_wcwidth.cpp to have its wcwidth implementation return 2 for
\u26a1. This fixes the behavior, but the symbol is now rendered left-aligned
within the two cells it's getting (it looks like lightning plus space
character). I do not know if it should be centered or left-aligned, but this
may be another issue (would prefer centered).

There seem to be other problems with konsole's wcwidth, cf.
https://eev.ee/blog/2015/09/12/dark-corners-of-unicode/ Wouldn't using the
system's wcwidth (if available?) be preferable? This might also give more
consistent behavior across the system.

-- 
You are receiving this mail because:
You are the assignee for the bug.