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

[piotrunio-2004@wp.pl]

Dnia 26 kwietnia 2025 09:03 Eli Zaretskii <eliz at gnu.org> napisał(a):  Date: Fri, 25 Apr 2025 23:21:05 +0200  From: "piotrunio-2004 at wp.pl via Unicode" <unicode at corp.unicode.org>   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.   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.   The CHAR_INFO structure is defined as a 32-bit structure with 16 bits for attributes and 16 bits for character code. The Win32 API allows for directly reading and writing arrays of that structure by using ReadConsoleOutput  and Write ConsoleOutput functions. This means that there is absolutely no way that a native Win32 console could possibly store its characters in a variable amount of bytes; in particular, the structure cannot store emoji +VC15, +VC16 sequences because it was never intended for that purpose.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://corp.unicode.org/pipermail/unicode/attachments/20250426/6b0c6775/attachment.htm>