From: Keith.S.Thompson+u@gmail.com   
      
   Keith Thompson  writes:   
   > bart  writes:   
   >> On 03/12/2025 19:01, James Kuyper wrote:   
   > [...]   
   >>> I find it confusing that this is supposed to "work perfectly"   
   >>> "across   
   >>> diverse OSs". The amount of space that a character takes up varies   
   >>> depending upon the installed fonts, especially on whether the font is   
   >>> monospaced or proportional. Those fonts can be different for display on   
   >>> screen or on a printer. I don't see any query to determine even what the   
   >>> current font is, much less what it's characteristics are. I don't know   
   >>> of any OS-independent way of collecting such information. Does this   
   >>> solution "work perfectly" only for your own particular favorite font?   
   >>   
   >> This looks like a solution for a fixed-pitch font. I get this output   
   >> for a Windows console display (with - used for space):   
   > [...]   
   >   
   > I think bart is right that this is specific to fixed-width fonts.   
   > For a variable width font, 'W' is going to be wider than '|'.   
   >   
   > See also the POSIX `int wcwidth(wchar_t wc)` function, which returns   
   > the "number of column positions of a wide-character code".  It does   
   > depend on the current locale.   
   >   
   > The assumption seems to be that fixed-width fonts are expected to be   
   > consistent about the widths of characters.   
      
   And in fact Unicode specifies how many cell positions each printable   
   character occupies, or at least for some of them.   
      
   The following is quoted from wcwidth.c in the xterm sources.  The text   
   was originally written by Markus Kuhn.   
      
    * For some graphical characters, the Unicode standard explicitly   
    * defines a character-cell width via the definition of the East Asian   
    * FullWidth (F), Wide (W), Half-width (H), and Narrow (Na) classes.   
    * In all these cases, there is no ambiguity about which width a   
    * terminal shall use. For characters in the East Asian Ambiguous (A)   
    * class, the width choice depends purely on a preference of backward   
    * compatibility with either historic CJK or Western practice.   
    * Choosing single-width for these characters is easy to justify as   
    * the appropriate long-term solution, as the CJK practice of   
    * displaying these characters as double-width comes from historic   
    * implementation simplicity (8-bit encoded characters were displayed   
    * single-width and 16-bit ones double-width, even for Greek,   
    * Cyrillic, etc.) and not any typographic considerations.   
      
   --   
   Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com   
   void Void(void) { Void(); } /* The recursive call of the void */   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)