Hello Richard,

On 13 Dec 16 09:43, Richard Menedetter wrote to Nicholas Boel:

 NB>> 1) Golded's area screen and message header's CP437 line drawings
 NB>> don't display properly in a UTF-8 console. 2) Most UTF-8 text is
 NB>> not displayed properly in Golded. 3) It will never be updated to
 NB>> support the above.

 RM> 3 good reasons ;)

Thanks. :)

 RM> I have a local JAMNNTP setup here as well ...
 RM> When I have some time I will look into it.

If not even for production and/or every day use, it's fun to see what you can
do with it, to say the least.

 RM> Also experimented a bit with OpenXP (Crosspoint).
 RM> Which supports FTN, IMAP, NNTP, etc.
 RM> But charset wise is worse than Golded.

I have only heard of this. Never set it up, though.

I've hammered at slrn and JamNNTPd the last couple days to see what I could
break. Even tested a couple recompiles that didn't seem to get me very far.
However, I can't find anything wrong in the UTF-8 realm as far as
reading/writing goes - even in the headers I seem to have no issue where I
thought there was an issue where in a UTF-8 message body, the headers were
still sent out as ISO-8859-1. I didn't see that problem when using a fully
functional UTF-8 console and slrn's iconv support is pretty rock solid as well.

The only issue I see with this combination (and it exists everywhere as
JamNNTPd doesn't currently support it and is specifically coded to only use
level 1 and 2 in the current code) is when using the CHRS kludge, your message
is sent out with "CHRS: UTF-8 2" which is invalid. The level parameter for
UTF-8 should always be 4. If I could somehow fix that I would be all set. I
could choose NOT to use the CHRS kludge, but that won't help anyone else when
reading my messages that do in fact contain UTF-8 characters.

We'll see where I can get with it. It gives me something half way interesting
to do while I'm bored. :)

Regards,
Nick

... "Не знаю. Я здесь только работаю."
--- GoldED+/LNX 1.1.5-b20160827