KE>> Well I dont know what I did, but some time ago I did some tinkerimg. KE>> What surprises me is that almost half the exotic characters do resolve KE>> to the proper glyphs in my terminal emulator.
MvdV> Not bad considering that most console implementations only support a MvdV> limited subset of the Universal Character Set.
Well I think it should either work or not alt all, but it may be caused by some tinkering I did.
KE>> Things like UTF-8 4 can be manipulated with much hassle. But I still KE>> maintain, that in the xlat implementation in Golded it should be UTF-8 KE>> 2. As that is the type of translation table that is used.
MvdV> When writing this message, there is no translation used at all...
Well, when writing this messages there are a number of translations used. Some of then without pattern change.
KE>> If the CHSRS character family is fixed to a translation table type, KE>> then that type is redundant and has no use.
MvdV> The level parameter simply denotes the type of encoding. No more, no MvdV> less. Level 1 and 2 denote a one byte encoding. Level 3 is reserved for MvdV> two byte encoding and Level 4 denotes a (variable length) multy byte MvdV> encoding. It has nothing to do with any translation process. So when the MvdV> text is encoded is UTF-8, the level is 4. Independant of how the MvdV> encoding came into being.
Well in theory you may be right, in practice the implementations in Golded and jamnntpd use translation tables that only go to level 2.
There is no support for level 4, but you can trick to some results when declaring level 2. I do not care what the theory says, I am only interested in what works. Theory is for scolars.
KE>> My aguments sound familear, we must be a yearly pet peeve.
MvdV> That happens in the dark days before the festival of the Return Of The MvdV> Light. ;-)
No, the only time of the year that someone tries to demonstrate that UTF8 is needed in Fidonet. ;(
Kees
--- GoldED+/LNX 1.1.5 * Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)
