The reply I am writting now will likely have a kludge like LATIN-1.
It's nothing to worry about. It is there so the person reading your
mail can read it as expected.
The reply I am writting now will likely have a kludge like
LATIN-1.
It does.
It's nothing to worry about. It is there so the person reading
your mail can read it as expected.
But oddly enough Synchronat BBS anwers in CP437 when quote replying to
an UTF-8 encoded message...
@MSGID: 1:153/757.2 63fa8cca
@REPLY: 2:280/5555 63fa857a
@CHRS: LATIN-1 2
@TZUTC: -0800
@TID: hpt/lnx 1.9 2023-02-18
Hello Michiel,
I think this one will too.
If I remember right I setup golded to use that because by default it
uses "UTF-8 2". Not quite correct but closer to the truth.
All of my terminals here are UTF-8 although I don't see UTF-8
correctly in any of my readers, not on the BBS or when reading with golded.
I can setup golded to use an external editor and when I hit reply I
see the UTF-8 characters correctly.
But oddly enough Synchronat BBS anwers in CP437 when quote
replying to an UTF-8 encoded message...
Synchronet is generally good about the CHRS kludge but I guess it
doesn't look at the encoding of the reply. Perhaps it needs to be
looked at.
There is trick to make it "UTF-8 4". See my message.
Golded has its limits and do do many other Fidonet readers when it
comes to UTF-8.
Goated and Gosiped do it right.
Goated and Gosiped do it right.
I have read a bit about those but never had a look. Are they open source?
There is trick to make it "UTF-8 4". See my message.
What is the trick?
I have read a bit about those but never had a look. Are they open
source?
Hello Alan,
On Saturday February 25 2023 13:09, you wrote to Chris Jacobs:
The reply I am writting now will likely have a kludge like LATIN-1.
It does.
It's nothing to worry about. It is there so the person reading your mail can read it as expected.
But oddly enough Synchronat BBS anwers in CP437 when quote replying to an UTF-8 encoded message...
But oddly enough Synchronat BBS anwers in CP437 when quote replying to an UTF-8 encoded
message...
Re: codepage
By: Michiel van der Vlist to Alan Ianson on Sat Feb 25 2023 11:01 pm
But oddly enough Synchronat BBS anwers in CP437 when quote replying to an UTF-8 encoded
message...
And this reply is being written using a UTF-8 terminal.
But oddly enough Synchronat BBS anwers in CP437 when quote replyingto an UTF-8 encoded > message... And this reply is being written using
a UTF-8 terminal.
And this reply is being written using a UTF-8 terminal with some
actual non-ASCII characters:
Norco, CA WX: 42.0°F, 79.0% humidity, 0 mph NE wind, 0.15 inches rain/24hrs
Michiel van der Vlist wrote to Rob Swindell <=-
Hello Rob,
On Sunday February 26 2023 22:11, you wrote to me:
But oddly enough Synchronat BBS anwers in CP437 when quote replyingto an UTF-8 encoded > message... And this reply is being written using
a UTF-8 terminal.
And this reply is being written using a UTF-8 terminal with some
actual non-ASCII characters:
All three of your messages have non-ASCCI charcters. They all have the degree character '°' in the sign off, or whatver you call it. In the last message it is also present in the message test before the "--"
(two dashes).
Norco, CA WX: 42.0°F, 79.0% humidity, 0 mph NE wind, 0.15 inches rain/24hrs
Considering that the CHRS kludge applies to the entire message, I think it is more logical to look at the entire message including header,
footer en origin lines to determine the encoding.
Other than that: my comment was on Chris' message that was a
quote-reply to my message. He quoted the UTF-8 encoded text but the
reply was in CP437 thereby messing up the quote.
Chris seems to have a preference for doing away with "legacy"
encodings, so I was a bit surprised that his reply was encoded in CP437 instead of UTF-8.
Cheers, Michiel
--- GoldED+/W32-MSVC 1.1.5-b20130111
* Origin: Michiel's laptop (2:280/5555.1)
Other than that: my comment was on Chris' message that was a
quote-reply to my message. He quoted the UTF-8 encoded text but
the reply was in CP437 thereby messing up the quote.
Your message was not entirely UTF-8. It contained a legacy ö
That caused Notepad Kladblok to interpret all of it as legacy.
Hello Rob,
On Sunday February 26 2023 22:11, you wrote to me:
But oddly enough Synchronat BBS anwers in CP437 when quote replyingto an UTF-8 encoded > message... And this reply is being written using
a UTF-8 terminal.
And this reply is being written using a UTF-8 terminal with some
actual non-ASCII characters:
All three of your messages have non-ASCCI charcters. They all have the degree character 'ø' in the sign off, or whatver you call it. In the last message it is also present in the message test before the "--" (two dashes).
Norco, CA WX: 42.0øF, 79.0% humidity, 0 mph NE wind, 0.15 inches rain/24hrs
Considering that the CHRS kludge applies to the entire message, I think it is more logical to look at the entire message including header, footer en origin lines to determine the encoding.
All three of your messages have non-ASCCI characters. They all have
the degree character '°' in the sign off, or whatver you call it.
In the last message it is also present in the message test before
the "--" (two dashes).
Ah, true. But in the message I posted using a UTF-8 terminal, that
would have been a UTF-8 encoded "degree" symbol instead of a
CP437-encoded one (as would have been in the other messages, including this one).
Norco, CA WX: 42.0°F, 79.0% humidity, 0 mph NE wind, 0.15inches RS> rain/24hrs
Considering that the CHRS kludge applies to the entire message, I
think it is more logical to look at the entire message including
header, footer en origin lines to determine the encoding.
Synchronet does exactly that.
Hello Rob,
On Thursday March 02 2023 17:02, you wrote to me:
All three of your messages have non-ASCCI characters. They all have
the degree character 'ø' in the sign off, or whatver you call it.
In the last message it is also present in the message test before
the "--" (two dashes).
Ah, true. But in the message I posted using a UTF-8 terminal, that would have been a UTF-8 encoded "degree" symbol instead of a CP437-encoded one (as would have been in the other messages, including this one).
The message I am respondig to, is indeed encoded in CP437.
So let me get this straight:
1) If the message that is responded to, is encoded in CP437, Synchronet answers in CP437. Yes?
So what happens if the response does not fit into CP437?
What happens if the original message is encoded in a one byte encoding other than CP437?
2) If the message that is responded to is encoded in UTF-8, Synchronet answers in UTF-8 if the terminal theis used supports UTF-8. Yes?
So what happens in that case if the terminal does not support UTF-8?
Norco, CA WX: 42.0øF, 79.0% humidity, 0 mph NE wind, 0.15inches RS> rain/24hrs
My software translates the CP437 encoded degree sign into UTF-8 as you can see.
So let me get this straight:
1) If the message that is responded to, is encoded in CP437,
Synchronet answers in CP437. Yes?
No. The message response itself determines the encoding and only CP437 terminals can faithfully author CP437 encoded messages. If a UTF-8 terminal user responds to a CP437 encoded message (with non-ASCII
chars), the original message text is converted to UTF-8 before it is quoted and the response will be UTF-8. Unless there are no non-ASCII
chars in the response, in which case the response charset witll just
be ASCII.
So what happens if the response does not fit into CP437?
I think this question is making false assumptions.
What happens if the original message is encoded in a one byte
encoding other than CP437?
The only encodings Synchronet supports for message text are ASCII,
CP437, and UTF-8.
2) If the message that is responded to is encoded in UTF-8,
Synchronet answers in UTF-8 if the terminal that is used supports
UTF-8. Yes?
Yes.
So what happens in that case if the terminal does not support
UTF-8?
The message text would be converted to CP437 before being quoted and
the response would be in CP437.
My software translates the CP437 encoded degree sign into UTF-8 as
you can see.
Yup, most software does the same, when appropriate.
Hello Rob,
On Saturday March 04 2023 13:11, you wrote to me:
So let me get this straight:
1) If the message that is responded to, is encoded in CP437,
Synchronet answers in CP437. Yes?
No. The message response itself determines the encoding and only CP437 terminals can faithfully author CP437 encoded messages. If a UTF-8 terminal user responds to a CP437 encoded message (with non-ASCII chars), the original message text is converted to UTF-8 before it is quoted and the response will be UTF-8. Unless there are no non-ASCII chars in the response, in which case the response charset witll just
be ASCII.
I see... So it is the terminal - or whatever functions as its equivalent - and only the terminal that determines the encoding of the message at hand.
It is making assumtions, but they are not false I would say. Read on.. I will come back to that further down.
What happens if the original message is encoded in a one byte
encoding other than CP437?
The only encodings Synchronet supports for message text are ASCII, CP437, and UTF-8.
Hmmm... That leaves out a big part of Fidonet. These days the majority, maybe the vast majority is writen in a language that uses the Cyrillic alfabet and the encoding is CP866.
2) If the message that is responded to is encoded in UTF-8,
Synchronet answers in UTF-8 if the terminal that is used supports
UTF-8. Yes?
Yes.
OK, so far so good...
So what happens in that case if the terminal does not support
UTF-8?
The message text would be converted to CP437 before being quoted and the response would be in CP437.
And now I come back to my previous question: what happens if it does not fit into CP437? That can easely happen. A Euro sign '¨' can be composed in UTF-8 but it does not fit into CP437.
I see... So it is the terminal - or whatever functions as its
equivalent - and only the terminal that determines the encoding of the
message at hand.
Or rather, the message content created with that terminal. If the
content is just plain ASCII, regardless of the terminal that created
it, then the message will fly the ASCII charset flag. In Synchronet, a CP437 terminal cannot be used to created UTF-8 content, so messages created by such a terminal will either be ASCII or CP437 encoded.
The only encodings Synchronet supports for message text are
ASCII, CP437, and UTF-8.
Hmmm... That leaves out a big part of Fidonet. These days the
majority, maybe the vast majority is writen in a language that uses
the Cyrillic alfabet and the encoding is CP866.
True, that's the state of things.
So what happens in that case if the terminal does not support
UTF-8?
The message text would be converted to CP437 before being
quoted and the response would be in CP437.
And now I come back to my previous question: what happens if it
does not fit into CP437? That can easely happen. A Euro sign '¿'
can be composed in UTF-8 but it does not fit into CP437.
When a CP437 terminal user quotes a UTF-8 message that contains untranslatable UNICODE codepoints without a CP437 equivalent, they're translated to character that indiciates it was untranslatable. By
default, that character is the upside down question mark.
Next question: Can Synchonet deal with a UTF-8 encoded nodelist?
Synchronet does use an FTN nodelist. There are some optional scripts
that can make use of a nodelist (e.g. to look up a particular sysop name/address), but I don't use them personally.
Hello Rob,
On Monday March 06 2023 16:58, you wrote to me:
Next question: Can Synchonet deal with a UTF-8 encoded nodelist?
Synchronet does use an FTN nodelist. There are some optional scripts that can make use of a nodelist (e.g. to look up a particular sysop name/address), but I don't use them personally.
Ok, thanks for the feedback.
| Sysop: | Coz |
|---|---|
| Location: | Anoka, MN |
| Users: | 2 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 190:54:37 |
| Calls: | 184 |
| Calls today: | 1 |
| Files: | 5,413 |
| Messages: | 222,750 |