Odp: RE: Is emoji +VC15, +VC16, without VC one or two columns with monospace font?🏝️

[piotrunio-2004@wp.pl]

Unix-like terminals are terminals intended to display console text of programs for unix-like systems. I consider Windows Terminal to be a unix-like terminal as well since it is intended for unix-like compatibility after all.  "Unix-like terminal" is what I call it myself, in order to contrast them with non-Unix-like terminals which are generally random access semigraphical terminals that store each character cell in a constant amount of bytes (which in practice cannot be UTF-8 as that would imply wildly impractical widths).   What exactly do you mean by " escapes or UTF-8 [not being] exclusive to that [Unix-like] world "? Are you implying the existence of terminal emulator systems that use variable length character cells (and therefore do not use a random access array for the character grid), and yet also are not designed for Unix-like console output compatibility whatsoever? If those systems do exist, are those systems even on-topic?   Dnia 25 kwietnia 2025 23:57 Phil Smith III <lists at akphs.com> napisał(a):  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 <unicode-bounces at corp.unicode.org>  On Behalf Of  piotrunio-2004 at wp.pl via Unicode  Sent:  Friday, April 25, 2025 5:21 PM  To:  Дилян Палаузов via Unicode <unicode at corp.unicode.org>; Дилян Палаузов <b at bapha.be>  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 <  unicode at corp.unicode.org > napisał(a):  Hello,     www.unicode.org https://www.unicode.org/errata/  contains a hyperlink under “Reporting Errors” behind “contact form” to  corp.unicode.org 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  gitlab.gnome.org 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  github.com 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 :  cal.aegee.org https://cal.aegee.org/s/0/e947872a-224b-4c84-8d25-90a541a9ec6-318.ics_en.html  .     Kind regards  Дилян
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://corp.unicode.org/pipermail/unicode/attachments/20250426/664aacb2/attachment-0001.htm>