TZUTC: -0700   
   MSGID: 52587.syncprog@1:103/705 2d22e1b8   
   PID: Synchronet 3.21a-Linux master/27cbebcb9 Aug 10 2025 GCC 12.2.0   
   TID: SBBSecho 3.29-Linux master/93b4d946c Sep 03 2025 GCC 12.2.0   
   BBSID: VERT   
   CHRS: UTF-8 4   
   FORMAT: flowed   
   https://gitlab.synchro.net/main/sbbs/-/merge_requests/569#note_7580   
      
   Yeah, actually this probably isn't what I want to do.  The problem I'm seeing   
   seems to stem from not being able to get an accurate string length for some   
   UTF-8 strings.  I've been using console.strlen() with P_AUTO_UTF8 to get   
   printed string lengths, and DDLightbarMenu uses these string lengths to ensure   
   that text fields of specific widths within a menu item are filled in with the   
   specified attributes. The attributes might have a background color, and what   
   I'm seeing is that sometimes, console.strlen() reports a UTF-8 string length   
   as more than what's actually printed on the screen, and the result is that the   
   menu item text isn't always fully filled in with the set attributes.  For   
   example, in the following screenshot, there is some text that has 5   
   upside-down question marks (I believe where UTF-8 text can't be displayed);   
   the blue background color should stretch the full width of the text, but   
   there's a block missing where it's just black:   
   ![Email_list_item_UTF8_len_issue](/uploads/27efc93acbb4af1490387   
   14851b25a5/Email_list_item_UTF8_len_issue.png)   
      
   I have some JS code that demonstrates the string length issue:   
      
   `var str = "リそな銀行";   
   console.print(str, P_AUTO_UTF8);   
   console.crlf();   
   console.print("Str length: " + console.strlen(str, P_AUTO_UTF8) + "\r\n");`   
      
   In SyncTerm (not supporting UTF-8), the text string appears as "¿¿¿¿¿",   
   which is 5 characters long, but the string length reported by console.strlen()   
   here is 10.  So my script would think more characters were printed than there   
   actually are.   
      
   I had made a workaround that involves using console.getxy() to get the current   
   cursor position and calculating the remaining width to fill in, but I don't   
   feel like that's an ideal solution, as it is noticeably slow.   
   --- SBBSecho 3.29-Linux   
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)   
   SEEN-BY: 10/0 1 102/401 103/1 705 105/81 106/201 124/5016 128/187   
   SEEN-BY: 129/14 153/7715 154/110 214/22 218/0 1 215 610 700 810 226/30   
   SEEN-BY: 227/114 229/110 206 317 400 426 428 470 700 705 266/512 280/464   
   SEEN-BY: 291/111 301/1 320/219 322/757 342/200 396/45 460/58 633/280   
   SEEN-BY: 712/848 902/26 5075/35   
   PATH: 103/705 218/700 229/426