Text 7079, 54 rader
Skriven 2014-01-06 00:04:36 av Kees van Eeten (2:280/5003.4)
   Kommentar till text 7078 av Maurice Kinal (1:153/7001.0)
Ärende: all over but the crying?
================================
Hello Maurice!

 I may seem dense, but I think I am finally with you. We care describing
 two differnt worlds. You are describing correct implementations such
 aas are pobably available in Linux. That is also my working environment,
 and what you explain is what happens if I use the available conversion
 tools.

 From your words I gather that a UTF-8 file can either contain 8 bit
 code points or the multibyte presentation.

 Your presentation environment is UTF-8, so if a multibyte UTF-8 messages
 arrives, the conversion is bypassed, and you get the proper charaters on
 your screen. If you write a message you export UTF-8, so there is no
 conversion and a multibyte encoded UTF-8 file is created. All nice and well.

 Now your message arrives on a different system, where the native presentation
 is either one of the CPxxx codepages or latin-1.

 The only conversion available, is the internal conversion in Golded.
 That converter can as far as a can see, only accept 8 bit input and multibyte
 output, but that is not relevant here.

 Your utf-8 multibyte encoded message arrives on this system and the bytes
 in the message are presented one by one to the converter. There are
 bound to be problems as multibyte characters cannot be isolated.

 To make it even worse, the avalable translation table is laid out to convert
 a input from a real 8bit encoded UTF-8 message, so the converter thinks
 it is getting UTF-8 codepoints hence the presentation of A tile and cidilla
 for every slashed o to put into your message.

 Now I am only talking about the conversion implementation in GOLDED, with
 other message editors yor milage may differ.

 There seems to be no way, that GOLDED can convert multibyte UTH-8 to pure
 8 bit code pages. So every time an exotic character that takes two bytes
 is used, the receiver will be presented with two weird characters.

 Somebody should replace the use of the internal conversion to a call to
 iconv() that is standard in the libraries on a linux system.

 I like my messages to be true 8 bit files, so I use GOLDED in a LATIN-1
 environment and I encapsulate GOLDED in "luit" to match the LATIN-1 to
 my UTF-8 desktop. I do not now it the UTF-8 that luit produces is
 8bit UTF-8 codepoints or multibyte UTF-8, neither do I care.

 The negative here is that I cannot properly present a multibyte UTF-8
 messages, as the converter in GOLGED cannot cope.

Kees

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