Re: Is emoji +VC15, +VC16, without VC one or two co lumns with monospace font?🏝
Giacomo Catenazzi via Unicode <[email protected]> Mon, 28 Apr 2025 11:48:24 +0200
| Newsgroups | gmane.text.unicode.general |
|---|---|
| Message-ID | <[email protected]> |
On 2025-04-26 12:51, Eli Zaretskii via Unicode wrote: >> From: Dilyan Palauzov <[email protected]> >> Cc: [email protected] >> Date: Sat, 26 Apr 2025 12:00:50 +0300 >> >> From: Eli Zaretskii <[email protected]> >> 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