Hallo Richard!

Please quote the line below;

Wide ne bi� wel, cw�� se �e gehyrde on helle hriman.

It is English so there should be no problem with echo rules.

Het leven is goed,
Maurice

... Huil niet om mij, ik heb vi.
--- GNU bash, version 4.4.23(1)-release (x86_64-bonnell-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

Hi Maurice!

05 Jun 2018 14:26, from Maurice Kinal -> Richard Menedetter:

Please quote the line below;
Wide ne bi� wel, cw�� se �e gehyrde on helle hriman.
It is English so there should be no problem with echo rules.

I am no native english speaker.
So could you please translate line 2 above for me.
I do understand line 1 and 3.
I do not recognize line 2 as being in proper english, neither does google.

Hexdump of message text:

0000 48 61 6C 6C 6F 20 52 69 63 68 61 72 64 21 0D 0D Hallo Richard!.. 0010 50 6C 65 61 73 65 20 71 75 6F 74 65 20 74 68 65 Please quote the 0020 20 6C 69 6E 65 20 62 65 6C 6F 77 3B 0D 0D 57 69 line below;..Wi 0030 64 65 20 6E 65 20 62 69 FE 20 77 65 6C 2C 20 63 de ne bi� wel, c 0040 77 E6 FE 20 73 65 20 FE 65 20 67 65 68 79 72 64 w�� se �e gehyrd 0050 65 20 6F 6E 20 68 65 6C 6C 65 20 68 72 69 6D 61 e on helle hrima 0060 6E 2E 0D 0D 49 74 20 69 73 20 45 6E 67 6C 69 73 n...It is Englis 0070 68 20 73 6F 20 74 68 65 72 65 20 73 68 6F 75 6C h so there shoul 0080 64 20 62 65 20 6E 6F 20 70 72 6F 62 6C 65 6D 20 d be no problem
0090 77 69 74 68 20 65 63 68 6F 20 72 75 6C 65 73 2E with echo rules. 00A0 0D 0D 48 65 74 20 6C 65 76 65 6E 20 69 73 20 67 ..Het leven is g 00B0 6F 65 64 2C 0D 4D 61 75 72 69 63 65 0D 0D 2E 2E oed,.Maurice.... 00C0 2E 20 48 75 69 6C 20 6E 69 65 74 20 6F 6D 20 6D . Huil niet om m 00D0 69 6A 2C 20 69 6B 20 68 65 62 20 76 69 2E 0D 2D ij, ik heb vi..- 00E0 2D 2D 20 47 4E 55 20 62 61 73 68 2C 20 76 65 72 -- GNU bash, ver 00F0 73 69 6F 6E 20 34 2E 34 2E 32 33 28 31 29 2D 72 sion 4.4.23(1)-r 0100 65 6C 65 61 73 65 20 28 78 38 36 5F 36 34 2D 62 elease (x86_64-b 0110 6F 6E 6E 65 6C 6C 2D 6C 69 6E 75 78 2D 67 6E 75 onnell-linux-gnu 0120 29 0D 20 2A 20 4F 72 69 67 69 6E 3A 20 4C 69 74 ). * Origin: Lit 0130 74 6C 65 20 4D 69 6B 65 79 27 73 20 45 75 72 6F tle Mikey's Euro 0140 50 6F 69 6E 74 20 2D 20 4C 61 64 79 73 6D 69 74 Point - Ladysmit 0150 68 20 42 43 2C 20 43 61 6E 61 64 61 20 28 32 3A h BC, Canada (2: 0160 32 38 30 2F 34 36 34 2E 31 31 33 29 0D 00 00 00 280/464.113)....

CU, Ricsi

--- GoldED+/LNX
* Origin: Man's horizons are bounded by his vision. (2:310/31)

Hallo Richard!

So could you please translate line 2 above for me.

I have done this multiple times now but since you asked nicely here we go again; Things are bad everywhere, said the man who heard wailing in hell.

Anyhow I see the your quote of line 2 which I converted to latin1 before packing confirms the your editor's LATIN-1 kludge is more than likely ISO-8859-1 although it still might be CP1252 which often it is. The hexdump was a nice touch although not really needed. Of note is the 0xfe character which got buggered up on a test of a so-called LATIN-1 editor I did not too long ago with the exact same line. Obviously a buggy version of so-clled LATIN-1. No?

Het leven is goed,
Maurice

... Huil niet om mij, ik heb vi.
--- GNU bash, version 4.4.23(1)-release (x86_64-bonnell-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

Hi Maurice!

10 Jun 2018 19:20, from Maurice Kinal -> Richard Menedetter:

Anyhow I see the your quote of line 2 which I converted to latin1
before packing confirms the your editor's LATIN-1 kludge is more than likely ISO-8859-1

I already told you at least 3 times, and I quoted the FTS that describes that the LATIN-1 charset kludge refers to the ISO 8859-1 character set.

BTW, as you do not use the CHRS Kludge I had to manually set it to LATIN-1 decoding.
I have configured my editor to assume CP850 (DOS Latin1) charset, as that is what some ancient german pointsoftware uses.
Most other messages either have a correct CHRS kludge, or not use any characters above 127 (ASCII).

Obviously a buggy version of so-clled LATIN-1. No?

Fix the bug in your editor and submit a patch!

UTF-8 is the only universal encoding.

Yes ... but again ... if people cannot read what you write, then it is not really helpful to communicate.
For the languages I speak English (ASCII), German (ISO 8859-1 or ASCII if you do not use Umlauts) and Hungarian (ISO 8859-2 or ISO 8859-1 if you do not use long umlauts) i do not need UTF-8.

It is the same with Esperanto ... a very nice idea, but it is not really helpful if you try to talk Esperanto to only English speaking people.

BTW Golded has a Copyright message of 1990.

UTF-8 (the current standard)
ISO/IEC 10646-1:2000 Annex D (2000)

The older definition:
ISO/IEC 10646-1:1993 Amendment 2 / Annex R (1996)

So Golded was written before UTF-8 came out.
There were some Unicode variants before ... but they were used very seldom.

CU, Ricsi

--- GoldED+/LNX
* Origin: With free advice, you get what you paid for. (2:310/31)

Hallo Richard!

Fix the bug in your editor and submit a patch!

It isn't my editor to fix. It is part of a BBS package. I just used it to see
what would happen with the same Old English quote I posted to you (the 8 bit latin1 version). It obviously couldn't replicate it which is why I wanted a qoute from you, which as I know now does work.

I use vim on my machines, which is what I am using to reply to you. I avoid 8 bit encodings as a rule since they cause too much grief ... as you are so kindly demonstrating. ;-)

So Golded was written before UTF-8 came out.

I'll take your word for it. All I know for sure about golded, as well as msged, is that it (they) can display utf-8 characters but screws them up when quoting them back. However that can be compensated for by using an external editor for creating/replying to messages which is what I briefly did when using
msged way back when. Now I just use vim instead. Doesn't everyone? :::evil grin:::

Het leven is goed,
Maurice

... Huil niet om mij, ik heb vi.
--- GNU bash, version 4.4.23(1)-release (x86_64-bonnell-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

Hi Maurice!

10 Jun 2018 22:14, from Maurice Kinal -> Richard Menedetter:

I avoid 8 bit encodings as a rule since they cause too much grief ...
as you are so kindly demonstrating. ;-)

I had no grief whatsoever.
But I also do not have the need to send characters of languages that I do not speak.

All I know for sure about golded, as well as msged, is that it (they)
can display utf-8 characters but screws them up when quoting them
back.

The problem seems that the way it was coded heavily relies on 8 bit value replacement ...
Some people tried to add UTF-8 support, but they gave up.

CU, Ricsi

--- GoldED+/LNX
* Origin: Stupidity got us in this mess, why can't it get us out. (2:310/31)

Hallo Richard!

But I also do not have the need to send characters of languages
that I do not speak.

I can relate especially considering that I haven't ever mastered the language I
speak, nevermind ones that I don't. Having said that I can see where utf-8 supported echoareas might improve the current situation in Fidonet. It is worth a shot ... maybe.

Some people tried to add UTF-8 support, but they gave up.

I don't blame them. For my part I just use an already capable editor (vim in my case but there are many others) and took it from there. One thing I've noticed is that it doesn't matter if a kludge is provided or not. Both golded and msged will screw them up with or without a CHRS kludge. It is a total waste of bytes and probably only encourages the FTSC powers that be to write further jibberish they call "standards". :::evil grin:::

Het leven is goed,
Maurice

... Huil niet om mij, ik heb vi.
--- GNU bash, version 4.4.23(1)-release (x86_64-bonnell-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

Hi Maurice!

12 Jun 2018 13:22, from Maurice Kinal -> Richard Menedetter:

But I also do not have the need to send characters of languages
that I do not speak.

I can relate especially considering that I haven't ever mastered the language I speak, nevermind ones that I don't.

I agree ... same here ;)

Having said that I can see where utf-8 supported echoareas might
improve the current situation in Fidonet.
It is worth a shot ... maybe.

It is a a balancing between the added value vs. how many people will not be able to use it.

For english discussion for me personally the value is very small, and the fact that most people will not be able to participate is bad.
So for me personally it is not a viable usecase currently.

If you take a look at how many people use fido packages which do not even support the generation of a REPLY kludge, I do not think that we will see widespread UTF-8 adoption in our lifetime.

Some people tried to add UTF-8 support, but they gave up.

I don't blame them.

Me neither.

Both golded and msged will screw them up with or without a CHRS
kludge.

What exactly do you mean?
I am using it daily and it works just fine within the scope of the implementation.
If I receive an 8 bit message in CP850, it will be correctly translated to ISO 8859-1 and displayed correctly.
(I am dumbin down my terminal to ISO 8859-1 in the golded start script.)

That those software packages have limited scopes is a different story.
IF they would support UTF-8, the implementation could correctly translate from eg CP850 to UTF-8.

CU, Ricsi

--- GoldED+/LNX
* Origin: For these prices, you can't expect real quotes. (2:310/31)

Hallo Richard!

What exactly do you mean?

Nothing like a real life example to make the point;

-={ '<Esc>:read ~/docs/squirrels.utf8' starts }=-
UTF-8 messaging can be fun for the whole family, especially Fidonet.

Case in point is when you find squirrels in your pants and lack a suitable search for a solution within the Fidonet family. With UTF-8 enabled then one could send a single message with, "I've got squirrels in my pants", "Jag har ekorrar i mina byxor", "У меня в штанах белка", "Έχω σκίουροι στο παντελόνι μου" and "Ich habe Eichhörnchen in meiner Hose", within a single message which covers five languages thus vastly increasing your coverage when searching for a solution to this most perplexing situation.

So, what are you waiting for? Enable UTF-8 Fidonet text messaging today and join in on the fun.
-={ '<Esc>:read ~/docs/squirrels.utf8' ends }=-

Note that I have turned on the CHRS kludge. I am betting it won't make a difference to your editor.

I am using it daily and it works just fine within the scope of the implementation.

Whose implimentation? Anyhow I enabled the CHRS kludge to FTSC specs, so if that is to be the acceptable measurement of implimentation, then a modern golded should have no issues with this test. There is even some LATIN1 in there but good luck converting the entire text to any 8-bit encoding including LATIN-1 whatever that really is. :::evil grin:::

Het leven is goed,
Maurice

... Huil niet om mij, ik heb vi.
--- GNU bash, version 4.4.23(1)-release (x86_64-bonnell-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

Hi Maurice!

12 Jun 2018 14:56, from Maurice Kinal -> Richard Menedetter:

What exactly do you mean?

Nothing like a real life example to make the point;

I could read english and german.
I could not read the rest. (because I cannot read that languages! it is not a matter of UTF-8 encoding, but a lack of knowledge of more than 4 languages.)

UTF-8 messaging can be fun for the whole family, especially Fidonet.

What difference does it make?
Most people (I assume >> 90% percent will NOT be able to see extended characters correctly, and moreover I cannot read them, no matter how they are encoded.)

So, what are you waiting for? Enable UTF-8 Fidonet text messaging
today and join in on the fun.

Why?
All languages I use in fidonet (English and German) are covered by 8859-1.
The additional characters I am unable to read ... so what do *I* gain by using UTF-8? (eg. for English UTF-8 and ASCII are the same ... you use the first 128 characters.

Note that I have turned on the CHRS kludge.
I am betting it won't make a difference to your editor.

Sure ... my editor does not support UTF-8, so naturally it does not make a difference.

But it WILL make a difference for Jamnntpd or Hotdoged, that DO support UTF-8.

I am using it daily and it works just fine within the scope of
the implementation.

a modern golded should have no issues with this test.

Golded is very, very far from modern.
(As is the whole Fidonet BTW).

I do not have an issue with that test.
It shows that I can see ASCII and 8859-1 without problems, and that extended characters are mangled (those characters which I would be incapable to read anyhow ...)
No new information from your test.

CU, Ricsi

--- GoldED+/LNX
* Origin: Monotheism is a gift from the gods! (2:310/31)

Hallo Richard!

What difference does it make?
Most people (I assume >> 90% percent will NOT be able to see
extended characters correctly

If by extended you mean multibyte then by the accounts I have read lately the majority of users can read them but I believe that has nothing to do with fidonet editors. From my observations even the old DOS editors that cannot properly display them can replicate them perfectly. So far only the 8-bit fidonet editors, such as golded+ and msged, that have issues replicating multibyte characters and in fact totally screw them up. So even abandonware DOS-think is superior to those products which is a very sad testiment to all things FTN compliant methinks.

As for what difference it makes, my guesstimation is probably no difference but
I still think it is/was worth the effort. We'll see I am sure.

But it WILL make a difference for Jamnntpd or Hotdoged, that DO
support UTF-8.

There you go. However I am doubtful about the CHRS kludge being required for either of them to recognize UTF-8 characters.

No new information from your test.

Don't be so sure. I don't see you using LATIN-1 for ISO-8859-1 in this latest reply, although 8859-1 isn't a legitimate alias either. Oh well, one step at a
time eh? :-)

-={ grep 8859-1// /usr/lib/gconv/gconv-modules }=-
alias ISO-IR-100// ISO-8859-1//
alias ISO_8859-1:1987// ISO-8859-1//
alias ISO_8859-1// ISO-8859-1//
alias ISO8859-1// ISO-8859-1//
alias ISO88591// ISO-8859-1//
alias LATIN1// ISO-8859-1//
alias L1// ISO-8859-1//
alias IBM819// ISO-8859-1//
alias CP819// ISO-8859-1//
alias CSISOLATIN1// ISO-8859-1//
alias 8859_1// ISO-8859-1//
alias OSF00010001// ISO-8859-1//
module ISO-8859-1// INTERNAL ISO8859-1 1 module INTERNAL ISO-8859-1// ISO8859-1 1

Het leven is goed,
Maurice

... Huil niet om mij, ik heb vi.
--- GNU bash, version 4.4.23(1)-release (x86_64-bonnell-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

Hi Maurice,

It looks good in Thunderbird, but it will probably get
mangled on the way back. ;((

On 06/12/2018 04:56 PM, Maurice Kinal -> Richard Menedetter wrote:

Hallo Richard!

What exactly do you mean?

Nothing like a real life example to make the point;

-={ '<Esc>:read ~/docs/squirrels.utf8' starts }=-
UTF-8 messaging can be fun for the whole family, especially Fidonet.

Case in point is when you find squirrels in your pants and lack a
suitable search for a solution within the Fidonet family. With UTF-8 enabled then one could send a single message with, "I've got squirrels
in my pants", "Jag har ekorrar i mina byxor", "У меня в штанах

белка",

"Έχω σκίουροι στο παντελόνι μου" and "Ich habe

Eichhörnchen in meiner

Hose", within a single message which covers five languages thus vastly increasing your coverage when searching for a solution to this most perplexing situation.

So, what are you waiting for? Enable UTF-8 Fidonet text messaging today and join in on the fun.
-={ '<Esc>:read ~/docs/squirrels.utf8' ends }=-

Note that I have turned on the CHRS kludge. I am betting it won't make
a difference to your editor.

I am using it daily and it works just fine within the scope of the
implementation.

Whose implimentation? Anyhow I enabled the CHRS kludge to FTSC specs,
so if that is to be the acceptable measurement of implimentation, then a modern golded should have no issues with this test. There is even some LATIN1 in there but good luck converting the entire text to any 8-bit encoding including LATIN-1 whatever that really is. :::evil grin:::

Het leven is goed,
Maurice

.. Huil niet om mij, ik heb vi.
--- GNU bash, version 4.4.23(1)-release (x86_64-bonnell-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada

(2:280/464.113)

---
* Origin: Fidonet!, isn't that something from the past? (2:280/5003.4)

Hallo Kees!

It looks good in Thunderbird, but it will probably get mangled
on the way back. ;((

It looks perfect here. I'll repost the parts that matter from a utf8 dump of 3
lines from your reply "MSGID: 2:280/5003.4 5b200566";

-={ '<Esc>:read dump.utf8' starts }=-

in my pants", "Jag har ekorrar i mina byxor", "У меня в штанах

белка",

"Έχω σκίουροι στο παντελόνι μου" and "Ich habe

Eichhörnchen in meiner

Hose", within a single message which covers five languages thus vastly

-={ '<Esc>:read dump.utf8' ends }=-

Note that is an exact replication from your reply (ie zero jiggery-pokery). I notice that Thunderbird does a perfect wordwrap given that it obviously counts multibyte characters the same as 7-bit ascii characters. Other web based apps I've seen don't as they count characters as bytes. Kudoes to your implimentation. :-)

Does the "CHRS: UTF-8 4" kludge make any difference at all? If so I'll turn it
on here but just so you know it is a total waste of bytes at this end since utf-8 characters work 100% at this end without any interference or help required.

Het leven is goed,
Maurice

... Huil niet om mij, ik heb vi.
--- GNU bash, version 4.4.23(1)-release (x86_64-bonnell-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

Hello Maurice!

Answering from Golded now, as that is my regular Fido mail reader.

16 Jun 18 16:04, you wrote to me:

-={ '<Esc>:read dump.utf8' starts }=-

in my pants", "Jag har ekorrar i mina byxor", "У меня в
штанах белка", "Έχω σκίουροι στο
παντελόνι μου" and "Ich habe Eichhörnchen in meiner
Hose", within a single message which covers five languages thus vastly

-={ '<Esc>:read dump.utf8' ends }=-

Ofcourse it does not look goed here, but neither did it in Thunderbird.
The smapinntpd that is in between wants the CHAR kludge. I have set de defaul
to some CPxxx to cover messages from mailers from before the kludge was
intruduced.

It does look good on my Python message reader, as there the kludge is ignored
a different method is used to define the characterset.

Note that is an exact replication from your reply (ie zero jiggery-pokery). I notice that Thunderbird does a perfect wordwrap given that it obviously counts multibyte characters the same as 7-bit ascii characters. Other web based apps I've seen don't as they count characters as bytes. Kudoes to your implimentation. :-)

Does the "CHRS: UTF-8 4" kludge make any difference at all? If so I'll turn it on here but just so you know it is a total waste of bytes at this end since utf-8 characters work 100% at this end without any interference or help required.

So yes it makes a difference, but for me olt when I read messages in
Thunderbird. As that seldom happens, just do as you like.

If I want to read a UTF-8 encoded message I can always read it in my
other message reader. The only drawback there is that I have never added a
message editor.

That again is lazyness, apart from the editor, it needs routines to
insert the message in the squish message base. For reading messages you
can take a few shortcuts, but for inserting messages a proper implementation
is needed. Maybe, oneday I will make such a beats for either squish or jamm.

Kees

--- GoldED+/LNX 1.1.5
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hallo Kees!

Answering from Golded now, as that is my regular Fido mail
reader.

Which explains the shoddy wordwrapping. ;-) It was perfect before this reply.

Ofcourse it does not look goed here, but neither did it in
Thunderbird.

Too bad. The wordwrapping was perfect although it would have easily been wider
(more characters) at this end. However I imagine on a smaller screen such as found on smartphones it wouldn't have looked goed simply because of the hardcoded 0x0d's for "normal" 80 character screens. Offhand I think most smartphones are around 60-ish characters at best. That is one reason I only put in 0x0d's to seperate paragraphs and leave wordwrapping up to the enduser's
device.

just do as you like

:-) I believe that goes without saying but thank you anyhow. It was nice to see the multibyte characters properly wordwrapped for a change so if for no other reason thank you for the qoute back.

Het leven is goed,
Maurice

... Huil niet om mij, ik heb vi.
--- GNU bash, version 4.4.23(1)-release (x86_64-bonnell-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)

Hello Kees!

12 Jun 2018 19:39, Kees van Eeten wrote to Maurice Kinal:

It looks good in Thunderbird, but it will probably get
mangled on the way back. ;((

if thunderbird use iso-8859-1 on outgoing mails, it will be safely put into fidonet readers that understand latin-1, but if anything is rewrited on incomming to thunderbird its safe to use utf-8

simple magic

one day fidonet users understand the limits


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.1.2 (Linux/4.17.2-gentoo (x86_64))
* Origin: I will always keep a PC running CPM 3.0 (2:230/0)

Hello Maurice!

16 Jun 2018 16:04, Maurice Kinal wrote to Kees van Eeten:

-={ '<Esc>:read dump.utf8' starts }=-

in my pants", "Jag har ekorrar i mina byxor", "�� �+����� �#
�����#��#�� �#���+�|�#", "+��� ��+|+�++���+++| ���++
��+#+���+�++��+�+| ++++��" and "Ich habe Eichh|�rnchen in meiner Hose",
within a single message which covers five languages thus vastly

-={ '<Esc>:read dump.utf8' ends }=-

looks binarie to me :)

Note that is an exact replication from your reply (ie zero jiggery-pokery). I notice that Thunderbird does a perfect wordwrap
given that it obviously counts multibyte characters the same as 7-bit ascii characters. Other web based apps I've seen don't as they count characters as bytes. Kudoes to your implimentation. :-)

what implementation ?

Does the "CHRS: UTF-8 4" kludge make any difference at all? If so
I'll turn it on here but just so you know it is a total waste of bytes
at this end since utf-8 characters work 100% at this end without any interference or help required.

msged is opensource, please add unicode solution to it :)

Het leven is goed,

i got a new cat.... :|)


Regards Benny

... there can only be one way of life, and it works :)

--- Msged/LNX 6.1.2 (Linux/4.17.2-gentoo (x86_64))
* Origin: I will always keep a PC running CPM 3.0 (2:230/0)

Hallo Benny!

msged is opensource, please add unicode solution to it :)

Yes it is but it is tied in to other sources/dependencies that would also require fixing. Also I don't believe that 8-bit has been properly addressed nevermind multibyte. Same with golded. However vim already can handle it all which makes it perfect as a base editor just like offline packages do, such as QWK and Bluewave except without needing the non-FTN formats. At the moment I am using a format not too far removed from fidonet's packed MSG format except without the binary data which just gets in the way and has absolutely no practical purpose. Bottomline is that it already works and doesn't require any
hacking.

i got a new cat.... :|)

I still have the same one;

-={ '<Esc>:read !cat --version' starts }=-
cat (GNU coreutils) 8.29
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>. This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Torbjorn Granlund and Richard M. Stallman.
-={ '<Esc>:read !cat --version' ends }=-

Works like a charm.

Het leven is goed,
Maurice

... Huil niet om mij, ik heb vi.
--- GNU bash, version 4.4.23(1)-release (x86_64-bonnell-linux-gnu)
* Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)