REPLY: 1:154/10 65496a63   
   MSGID: 1:104/117 65496e5f   
   CHRS: US-ASCII 2   
   TZUTC: -0700   
   TID: hpt/lnx 1.9 2022-07-03   
   Hello Nicholas.   
      
   06 Nov 23 16:25, you wrote to me:   
      
    VA>> ???A???????B, Nicholas!   
    VA>> 05 Nov 23 19:03, ?B?? ??????????(??) ??????:   
    NB> I may not be able to read some of the above, but it sure looks nice!   
    NB> ;)   
      
   Sorry. Forgot to switch my template. :)   
      
    VA>> My plan is to enhance conversion code which uses iconv in linux   
    VA>> builds. And then you won't need any translation tables for   
    VA>> charsets known by iconv. It will take some time, because changes   
    VA>> are not so small.   
    NB> Would you suggest going back to the b20231028 code then until you're   
    NB> done messing around with it?   
      
   Yes. Actually, I have an easy fix which will work with your setup without   
   issues. Will try to deliver it today.   
      
    VA>>>> Just in case - you understand, that GoldEd can't properly work   
    VA>>>> with UTF-8 local charset if any international character used?   
    NB>>> Do you have any examples?   
    VA>> GoldEd charset translation code can translate one byte encodings   
    VA>> to multibyte, but not the opposite.   
      
    VA>> So if you write your message in CP437 and export it to UTF-8 - it   
    VA>> will work fine if such translation table exists. Now imagine that   
    VA>> your local charset is CP437 and message is in UTF-8. That won't   
    VA>> work because translation tables size is only 256 bytes and UTF-8   
    VA>> code may have up to 6 bytes per code point.   
    NB> Ah yes. Understood. My local charset is UTF-8. Sometimes I try to do   
    NB> translations of incoming messages, but that's about it.   
      
   I use KOI8-R in my case to be able to read russian messages.   
      
    VA>> External editor solves some issues, but not all. Would be cool to   
    VA>> have UTF-8 used for internal string representation, but that's   
    VA>> huge work.   
    NB> It solves most, at least for Fidonet messaging. Most messages are   
    NB> US-ASCII, CP437/850, CP866, or UTF-8, which I can handle here just   
    NB> fine.   
      
   Because they use first 128 symbols of char table, which is exact same. :)   
      
    VA>> What is your XLatLocalSet, XLatImport, XLatExport?   
      
    NB> All are currently set to UTF-8. However, sometimes I like to test   
    NB> XLatImport CP437. It helps on some messages, but since my locale is   
    NB> completely UTF-8 it isn't perfect, usually when related to ANSI escape   
    NB> sequences.   
      
   I see. And you use that fake conversion table from/to UTF-8, right? If you do   
   - my next small fix will help you for sure.   
      
   Vitaliy   
      
   ... Hu??o ?e6? ?a ???? ?e ???y?! [????u?u?u?]   
   --- GoldED+/LNX 1.1.5-b20231030   
    * Origin: Aurora, Colorado (1:104/117)   
   SEEN-BY: 1/19 123 15/0 16/0 18/200 19/10 37 50/109 90/1 103/705 104/117   
   SEEN-BY: 105/81 106/201 123/130 131 124/5016 129/305 142/104 153/757   
   SEEN-BY: 153/7715 154/10 203/0 218/700 221/0 1 6 360 226/30 227/114   
   SEEN-BY: 229/110 112 113 206 307 317 400 426 428 452 470 664 700 240/1120   
   SEEN-BY: 240/5832 266/512 280/464 5003 5555 282/1038 291/111 292/854   
   SEEN-BY: 292/8125 301/1 305/3 310/31 317/3 320/119 219 319 2119 322/0   
   SEEN-BY: 322/757 326/101 341/66 234 342/200 396/45 423/81 120 460/16   
   SEEN-BY: 460/58 256 1124 5858 463/68 467/888 633/280 712/848 770/1   
   SEEN-BY: 3634/12 5000/111 5001/100 5005/49 5015/46 5020/400 828 846   
   SEEN-BY: 5020/1042 4441 5030/49 5054/8 30 5061/133 5075/128 5083/444   
   SEEN-BY: 5090/958   
   PATH: 104/117 5020/1042 460/58 280/464 221/1 320/219 229/426