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

Giacomo Catenazzi cate at cateee.net
Mon Apr 28 04:48:24 CDT 2025


On 2025-04-26 12:51, Eli Zaretskii via Unicode wrote:
>> From: Dilyan Palauzov <b at bapha.be>
>> Cc: unicode at corp.unicode.org
>> Date: Sat, 26 Apr 2025 12:00:50 +0300
>>
>> From: Eli Zaretskii <eliz at gnu.org>
>> Subject: Re: Is emoji +VC15, +VC16, without VC one or two columns with monospace font?🏝️
>> Date: 26/04/25 10:02:48
>>
>>> I think you have very outdated mental model of how the Windows console works and how it represents and encodes characters.
>>> In particular, the width of a character is NOT determined by the length of its byte sequence, but by the font glyphs used to display those characters.
>> I am confused.  Does the width of an emoji/a character depend on the font (thus font designers decide this), or does it depend on EastAsianWidth.txt ?
> It depends on the font, but the font is supposed to go by what
> EastAsianWidth.txt says.

It is worse. We are discussing monospaced fonts, and so terminals may 
select where to display each characters (skipping all font hints) and 
overwriting part of character.

Also note: I do not like the division Unix/non-Unix:. "Unix" terminal 
had different interpretations. E.g. if we look the initial Unicode 
support of xterm (so the mother of many "unix pseudoterminals), we learn 
that it supported only "Unicode level 1" (and obsolete terminology in 
old Unicode standards, or just in ISO). So it did interpret each 
codepoint independently (so no combining codepoints).

Also a good documentation on width of characters in terminals: problems, 
solutions, and interpretation of width in many implementations, from 
gosthy (the new kid in the block): 
https://mitchellh.com/writing/grapheme-clusters-in-terminals.

giacomo







More information about the Unicode mailing list