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

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

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  Дилян