Subj : Re: Changes in golded+ sources
To : Nicholas Boel
From : Vitaliy Aksyonov
Date : Mon Nov 06 2023 03:49 pm
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.
