https://bugs.kde.org/show_bug.cgi?id=396435
--- Comment #22 from Mariusz Glebocki <m...@arccos-1.net> --- (In reply to Martin Hostettler from comment #21) > About the hangul: Konsole before this change did display NFD in a way that > looked correct to my untrained eye. After this change decomposed forms are > displayed as 1 wide and 2 narrow characters. At least OS X uses NFD for file > names, so i would expect that these decomposed forms will end up in places > where konsole will encounter them. Wow, I didn't know that. I'll send a patch which will change the widths to allow characters to compose. > For the regional indicator symbols: Those are a whole new bag of fun. I > wonder how other terminals handle emoji joining... > > glibc and glib (vte) consider them narrow. Unifont and Noto consider them > wide. And what users actually want to see is two of them joined together to > be a flag(supported in Noto seems to be 2 cells wide, not supported in > unifont). Konsole see two of them as 2 wide characters (i.e. 4 cells). > Interesting enough kitty displays a flag which is 4 cells wide. Not sure how > expected that is. > I wonder how much sense it makes to deviate from what glibc says when the > actual display is really not that great anyway (for flags / regional > indicator symbols). Nice idea in kitty. Looks as intended, but is still width-compatible (assuming each indicator is wide). Since glib(c) assume the indicators are narrow, it could be possible to display one wide flag and keep compatibility with wcwidth-using software (i.e. everything in ncurses, shells). It would work on FreeBSD too (wcwidth works only for 16 bit code points, higher CPs are narrow). Not sure how it would work on macOS. > I'm worried about proliferation of lots of slightly different width mapping > functions that applications *somehow* have to know about. > > tangent: > I think in the long run we need some way for applications to download the > actually used width mapping from the terminal to get decent interoperability > across versions and different machines in a network. I just notices that > emoji joining is yet another aspect that needs to be kept in sync between > terminal and the application. There is already POSIX solution which could solve that - wcwidth() and wcswidth(). The latter could even calculate widths of joined emojis. Sadly, it works differently on every platform. And there are separate implementations in Go, Python, etc. This is why terminals and console programs sometimes try to make its own table which works the same (or at least is up to date) on every platform. Or, if someone likes hacks, LD_PRELOAD=libkonsole_wcwidth.so ;) -- You are receiving this mail because: You are watching all bug changes.
