<div><br></div><div class="nh_extra"><p>Dnia 26 kwietnia 2025 09:37 Eli Zaretskii <eliz@gnu.org> napisał(a):<br></p><blockquote class="nh_quote" style="border-left: 2px solid #999; padding-left: 8px; margin: 0;"><div id="gwp361cf64f"><blockquote><div>Date: Sat, 26 Apr 2025 09:15:02 +0200<br></div><div>Cc: unicode@corp.unicode.org <unicode@corp.unicode.org>,<br></div><div>       b@bapha.be <b@bapha.be><br></div><div>From: "piotrunio-2004@wp.pl via Unicode" <unicode@corp.unicode.org><br></div><div><br></div><div><br></div><div>Dnia 26 kwietnia 2025 09:03 Eli Zaretskii <eliz@gnu.org> napisał(a):<br></div><div><br></div><div>Date: Fri, 25 Apr 2025 23:21:05 +0200<br></div><div>From: "piotrunio-2004@wp.pl via Unicode" <unicode@corp.unicode.org><br></div><div><br></div><div>In non-Unix-like terminals, the width is always linearly proportional to the amount of bytes that the<br></div><div>text takes<br></div><div>in memory, because that is how a random access array works. Each character cell takes a<br></div><div>constant amount<br></div><div>of bytes, for example in VGA-compatible text mode there are 16 bits per character cell (8 bits for<br></div><div>attributes<br></div><div>and 8 bits for character code), and in Win32 console there are 32 bits per character cell (16 bits<br></div><div>for<br></div><div>attributes and 16 bits for character code). Whether a character is fullwidth may be determined by<br></div><div>the text<br></div><div>encoding (some legacy encodings such as Shift JIS will store fullwidth characters in the bytes of<br></div><div>two<br></div><div>consecutive character cells) or by attributes.<br></div><div><br></div><div>I think you have very outdated mental model of how the Windows console<br></div><div>works and how it represents and encodes characters.  In particular,<br></div><div>the width of a character is NOT determined by the length of its byte<br></div><div>sequence, but by the font glyphs used to display those characters.<br></div><div><br></div><div>The CHAR_INFO structure is defined as a 32-bit structure with 16 bits for attributes and 16 bits for character<br></div><div>code. The Win32 API allows for directly reading and writing arrays of that structure by using<br></div><div>ReadConsoleOutput and WriteConsoleOutput functions. This means that there is absolutely no way that a<br></div><div>native Win32 console could possibly store its characters in a variable amount of bytes; in particular, the<br></div><div>structure cannot store emoji +VC15, +VC16 sequences because it was never intended for that purpose.<br></div></blockquote><div><br></div><div>You seem to assume that the layout of characters in memory is the same<br></div><div>as their layout on display.  This was true for MS-DOS terminals, but<br></div><div>is no longer true on modern Windows versions, where WriteConsoleOutput<br></div><div>and similar APIs do not write directly to the video memory.  Instead,<br></div><div>they write to some intermediate memory structure, which is thereafter<br></div><div>used to draw the corresponding font glyphs on display.  I'm quite sure<br></div><div>that the actual drawing on the glass is performed using shaping<br></div><div>engines such as DirectWrite, which consult the font glyph metrics to<br></div><div>determine the width of glyphs on display.  The actual width of<br></div><div>characters as shown on display is therefore not directly determined by<br></div><div>the amount of bytes the characters take in their UTF-16<br></div><div>representation.<br></div></div></blockquote></div><div><br></div><div>The legacy Win32 console does not use DirectWrite, so what you're describing seems to be Windows Terminal, which as I said is a unix-like terminal, it's not a native Win32 console at all. It can emulate a Win32 console, but it doesn't run it natively. This only further shows that emoji +VC15, +VC16 in terminals only exists in unix-like context.<br></div><div><br></div>