2 ms·
32 bits isn't really enough. One uses 24 bits for RGB, and the remaining 8 bits aren't really enough for the remaining graphics renditions that a modern termin
by JdeBP 6y ago
32 bits isn't really enough. One uses 24 bits for RGB, and the remaining 8 bits aren't really enough for the remaining graphics renditions that a modern terminal emulator should support.
Factor in things like the KiTTY underlining system, invisible, the little-recognized new (sic!) ECMA-48:1991 graphic renditions (encircled, framed, and overlined), and strikethrough; and one actually needs 13 to 14 bits (depending from how far one takes the KiTTY underlining system).
Moreover: No-one doing this style of terminal emulator really does Unicode properly. To do so actually involves having a string of one or more code points per cell, not simply exactly one. Some of the terminal emulators based upon external GUIs (e.g. X11) do do that, or approach it. (Although at the same time they take a giant leap backwards from video terminal semantics to paper terminal semantics, so it is a matter of swings and roundabouts. See https://unix.stackexchange.com/a/593613/5132 https://unix.stackexchange.com/a/593613/5132 .)
- asveikau 6y ago> 32 bits isn't really enough. One uses 24 bits for RGB, Yes, and as I mentioned you need to divide between FG and BG colors. All a little moot because it seems to me like the code uses 3 bits for color. > No-one doing this style of terminal emulator really does Unicode properly Indeed, both multi-char and multi-codepoint glyphs. I also think the whole "matrix of glyphs" thing breaks down pretty severely when you want BiDi support for instance. The article mentions someone working on UTF-8 support. I wonder what that looks like.