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