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

[piotrunio-2...@wp.pl via Unicode]

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 <li...@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-boun...@corp.unicode.org>  On Behalf Of  piotrunio-2...@wp.pl 
via Unicode  Sent:  Friday, April 25, 2025 5:21 PM  To:  Дилян Палаузов via 
Unicode <unicode@corp.unicode.org>; Дилян Палаузов <b...@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@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  Дилян