Stupid question time: What is a “Unix-like terminal”? Do you mean one that honors curses-type escape codes? Is that really what people call those? It’s not like escapes or UTF-8 are exclusive to that world.
From: Unicode <[email protected]> On Behalf Of [email protected] via Unicode Sent: Friday, April 25, 2025 5:21 PM To: Дилян Палаузов via Unicode <[email protected]>; Дилян Палаузов <[email protected]> Subject: Odp: Is emoji +VC15, +VC16, without VC one or two columns with monospace font?🏝️ In non-Unix-like terminals, the width is always linearly proportional to the amount of bytes that the text takes in memory, because that is how a random access array works. Each character cell takes a constant amount of bytes, for example in VGA-compatible text mode there are 16 bits per character cell (8 bits for attributes and 8 bits for character code), and in Win32 console there are 32 bits per character cell (16 bits for attributes and 16 bits for character code). Whether a character is fullwidth may be determined by the text encoding (some legacy encodings such as Shift JIS will store fullwidth characters in the bytes of two consecutive character cells) or by attributes. Unix-like terminals on the other hand are completely detached from the concept of random access semigraphical text, and do not have any relation between number of bytes and width, due to the use of UTF-8 and ANSI escape codes. This places them above the complexity of plain text, oftentimes reaching the complexity of rich text (unlike non-Unix-like terminals where their complexity is well below plain text), and therefore any definition of widths or heights is completely arbitrary because it's not backed by any random-access legacy compatibility consideration. Some Unix-like developers are making proportional fonts and calling them monospaced, so this really isn't something that can be reliably standardized at all. Dnia 25 kwietnia 2025 19:10 Дилян Палаузов via Unicode <[email protected] <mailto:[email protected]> > napisał(a): Hello, https://www.unicode.org/errata/ contains a hyperlink under “Reporting Errors” behind “contact form” to https://corp.unicode.org/reporting/error.html . The latter hyperlink does not exist. Terminals use monospace fonts. How wide should be an emoji there followed or not by Unicode Variation Selector 16? VTE is one terminal backend and for Desert island + Unicode variation selector 16 at https://gitlab.gnome.org/GNOME/vte/-/issues/2878 is stated that some intrinsic properties of a Unicode codepoint define the number of cells, and the glyph has to find its way into the designated area. Never the other way around, it's never the glyph dictating how many cells it will take up. tmux is a terminal tool that runs in many different terminals. For the same question Desert island + VC16 at https://github.com/tmux/tmux/issues/4475 is stated that “Current practice is for emoji to have a square aspect ratio, deriving from their origin in Japanese. For interoperability, it is recommended that this practice be continued with current and future emoji.” and square means width 2. As can be read on the above links there are very different opinions from developers of terminal emulators if Desert island + Unicode variation selector 16 should allocate one or two columns in monospace fonts. Likewise uncertainties with VC15 or without variation selectors. * Be more explicit in the Unicode standards for monospace rendering of emojis without Variation Selector, emoji + VC15, and emoji + VC16, if these allocate one or two columns. There is apparent a need to specify this in a way that is accepted by many developers of terminal emulators. I invite you also to participate in the discussions on the both links I mentioned above. There are many arguments in all directions. Sample with Desert Island + VC16 + space : https://cal.aegee.org/s/0/e947872a-224b-4c84-8d25-90a541a9ec6-318.ics_en.html . Kind regards Дилян
