[konsole] [Bug 402613] Unicode Playing Cards are cut off on the right (regression)

Egmont Koblinger bugzilla_noreply at kde.org
Thu Dec 27 23:47:27 GMT 2018


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

Egmont Koblinger <egmont at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |egmont at gmail.com

--- Comment #6 from Egmont Koblinger <egmont at gmail.com> ---
There's at least 3 sides to this story:

1. IIRC there used to be a bug in Konsole, it accidentally treated all non-BMP
characters (including the playing cards) as double wide ones. This was fixed
relatively recently. I'm sorry but I couldn't quickly find the related bug.
This bug might have easily led you into falsely assuming that these characters
should take up 2 cells.

2. There's the desired _logical_ behavior: Which characters should occupy one
logical cell and which characters should occupy two? E.g. if such a 🂱 character
is printed from the left margin, followed by "ab", then the cursor positioned
in the (1-based) 3rd column and the letter "x" is printed there, is it going to
overwrite "a" or "b", that is, will the text be "🂱xb" (the card is _logically_
double wide) or "🂱ax" (the card is _logically_ single wide)?

3. There's the _visual_ behavior: what happens when a glyph is wider than its
designated area (that is, 1 or 2 cells)? Should it push the rest of the line
visually (but not logically) to the right (Konsole used to do this within runs
of identical attributes, as far as I can tell), or cropped (apparently
Konsole's new behavior), or shrinked (Kitty does this as far as I recall) or
overflow to the next cell (e.g. VTE)?

3 is probably a matter of taste to some extent, every approach has pros and
cons.

As for 2:

For proper positioning of items, e.g. the right border of soliterm, and for
proper overwrites in ncurses and friends, it's crucial that the terminal and
the app agrees on the logical width (although the former visual strategy of
Konsole of pushing the rest of the line to the right isn't compatible with the
expectation of the right border properly aligning up). If there's a
misunderstanding, chances are that sooner or later everything falls apart big
time on the screen. The basis for this is agreement the Unicode property.

It would be nice if there was some improvement, e.g. if there was a way to
negotiate the behavior between the terminal and the app, and maybe even allow
to alter the behavior (I'm not even sure whether it should be the terminal or
the app that should be able to initiate such a request; probably the app). If
anything like this is done, it should be designed as a cooperation among some
key players (i.e. popular terminal emulators), and ideally not something that
Konsole (or any other emulator) implements as its own custom extension.

The terminal emulator deciding the logical width based on the font doesn't
sound like a good direction to me at all (imagine the debugging hell if every
font results in a different logical behavior), and is certainly incompatible
with headless emulators or ones that can have multiple views (like libvterm,
screen, tmux; also konsole if it allowed different fonts in its split view).

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


More information about the konsole-devel mailing list