@REPLY: 2:203/910 6a9beb95
@MSGID: 2:5075/35@fidonet 6a9c6873
@CHRS: UTF-8 4
@TZUTC: 0300
@TID: hpt/nbsd 1.9 2024-03-02
Hello Alexey!

Saturday September 05 2026 12:03, you wrote to me:
 AM> I have some issue, and not sure how to fix that.

 AM> In R20 echoes the bytes are 437/850. If Windows OEM is 866 --> those
 AM> messages turn into Cyrillic garbage. No CHRS is fine тАФ I have
 AM> XLATIMPORT CP437 in the group. The broken ones are the ones that do
 AM> say IBMPC.

 AM> Tried to use `XLATCHARSETALIAS CP850 IBMPC` globally, but it does
 AM> nothing here. On the unicode build `CHRS: IBMPC 2` never looks at the
 AM> alias table. The recoder decides it itself: UTF-8 session --> Windows
 AM> OEM page (GetOEMCP(), that gives 866 in this case). Aliases are only
 AM> used if the recoder fails and it falls back to the old .chs files.
 AM> IBMPC always "succeeds", so the alias is never reached.

 AM> Could XLATCHARSETALIAS (or a groupable XLATIBMPC) be honoured in
 AM> GRecoder::canonical() before GetOEMCP()?

 AM> GROUP R20
 AM>   MEMBER            R20*
 AM>   XLATIMPORT        CP437
 AM>   XLATEXPORT        CP850
 AM>   XLATCHARSETALIAS  CP850 IBMPC
 AM> ENDGROUP

 AM> Right now the alias line is ignored.

Added in a new snapshot:
https://github.com/evs38/golded-plus/releases/tag/golded-plus-1.1.5-20260905

 I still have a hard time understanding what to do with this IBMPC.
So, I`ve left it all up to the user to determine. In theory, it
should be CP437 in the Z1, CP850 in Eastern Europe, and CP866 in Russia,
Ukraine, and Belarus. Overall, it`s a very unfortunate character set that
means absolutely nothing.


Eugene

... It`s full of stars!
--- GoldED+/BSD 1.1.5-b20260905 (NetBSD 11.0 Intel Core Haswell)
 * Origin: FireFox Station (2:5075/35)
SEEN-BY: 154/10 203/0 240/5832 280/464 5003 5555
292/789 301/1 310/31 341/66
SEEN-BY: 460/58 5001/100 5015/46 5019/40 5020/715
1042 1146 5452 9696 5023/24
SEEN-BY: 5030/1081 5051/44 5075/21 35 6035/3
@PATH: 5075/35 280/5555 5020/715