[Golded-plus-talks] About CHRS & TZUTC

[Jesper <je...@da...>]

I'm currently not using GoldED+ myself but I receive a lot of mail from
people using it. Although GoldED+ *is* capable of functioning in an
international network like Fidonet its features are not always used, and
they are sometimes making things worse because the user has them
misconfigured.

In my opinion, CHRS and TZUTC are *fundamental* kludges in today's
Fidonet, but to my knowledge they are not used by default...? Today's
Fidonet software needs to be fool proof! There should be no way to
install GoldED+ without setting these options correctly.

The best solution would be if GoldED+ automatically could detect which
timezone the user lives in and which character set he's using and tag
the messages accordingly. Maybe this information could be obtained from
the operating system settings?

Next best would be if there was some kind of installation program (or
maybe a function that runs the first time the program is started?) that
asks the user about this and creates the necessary configuration.

Another solution would be to provide several archives for download, or
several default configuration files for different types of users. E.g.
one archive for Western Europeans living in CET (TZUTC=0100,
XLATEXPORT=LATIN-1), and one for Russians living in Moscow (TZUTZ=0300,
XLATEXPORT=CP866).

"CHRS: IBMPC" should be considered obsolete. In Russia IBMPC means
CP866, in Western Europe it probably means CP850, and in the USA it
means CP437. I'm linked to Russian areas, European areas and Z1 areas.
In these echo areas users from all parts of the world are participating.
It is impossible for me to get the charset parsing correct when the
message only is tagged with IBMPC, or worse, no CHRS kludge at all. My
suggestion is to use the CP<codepage> notation suggested by FSP-1013, or
to add a CODEPAGE kludge as some other message editors does.

[From the GoldED+ reference manual about "Character Translation":]

>        Confused? Yeah, I know - this is a confusing subject, and my
>        implementation and documentation is not perfect. Normally you will not
>        have to worry about it. Turn it off completely if you don't understand
>        it.

No, it is not confusing at all. The only consideration when using 8 bit
charsets is to ensure that the same charset is used for both ENCODING
and DECODING the message, otherwise the characters get messed up in the
process. ("Encoding" is the process of converting an abstract
"character" into a byte in a message (there are multi byte encodings as
well, used e.g. in Asia), while "decoding" is the reverse process). The
sender is responsible for inserting a CHRS kludge specifying which
encoding is used, and the receiver is responsible for parsing this
kludge and decode the message accordingly.

That's what I wanted to say. Otherwise I think GoldED+ is a great
product. Keep up the good work. :)

/Jesper (2:204/254)