[EMAIL PROTECTED] had written:
> Can you read this? [...] ????????
On Thu, 12 Jul 2001 18:38:32 -0700, Edward Cherlin wrote:
> No. I am using Eudora 5.1 on Windows 2000.
Eudora 5.1 cannot handle UTF-8. Recently, I have asked their
technical support how to process non-Western (e. g. Cyrillic)
mail, and they told me that there are various add-ons available,
each handling a particular 8-bit codepage, but no Unicode
capability.
Hence, on Fri, 15 Jun 2001, I filed the following suggestion:
| as my tests have shown, and as Eudora Technical Services
| has confirmed, Eudora does not currently (Version 5.1)
| support the UCS (i. e. Unicode and ISO/IEC 10646). Under
| Windows NT 4 (tested), and Windows 2000 (conjectured),
| Eudora does not even correctly paste plain-text strings
| that were copied from other windows.
|
| This lack of Unicode support is a significant flaw in your
| otherwise superb product; in case of an internationally
| operating enterprise, or a university (my case), this
| omission renders your product just unusable. In a world
| of increasing Unicode support (e. g. MS-Windows 98, ME,
| NT 4, 2000; Sun Solaris 8; MS-Word 97, MS-Office 20000;
| Netscape Navigator 4.7, Netscape Communicator 6 (in-
| cluding Messenger), MS Internet Explorer 5), an e-mail
| client without appropriate UCS support is simply an ana-
| chronism.
|
| Please consider implementing UCS support at your earliest
| opportunity.
|
| UCS comes in three encoding forms, viz. UTF-8, UTF-16,
| and UTF-32; for e-mail, UTF-8 is currently the most widely
| adopted of these. So, support for UTF-8 is most important
| for an e-mail client. Unicode 3.2 will have characters de-
| fined in the range above U+FFFF; so you should include full
| 21-bit support from the very beginning (this is particularly
| a problem with UTF-16, whilst UTF-8 and UTF-32 expand natur-
| ally to the 21-bit range).
|
| A good, usable integration of UCS support would operate in the
| following manner:
|
| - Product uses UCS internally, for all text strings, part-
| icularly for the message text.
|
| - Before sending a message, user can choose an encoding (the
| default still can be ASCII).
| � If the chosen encoding does not suit all characters con-
| tained in the message, user will be asked for another choice,
| product will suggest suitable encodings.
| � Alternatively, the product could automatically choose from
| a list of encodings, on account of the characters contained
| in the message, e. g. US-ASCII -> ISO 8859-1 -> UTF-8; of
| course, the user must be able to configure this list.
| � Of course, all messages sent will correctly anounce their
| respective encodings via MIME headers.
|
| - When receiving a message, the product displays the message ac-
| cording to its MIME headers.
| � The user can manually override the encoding given in those
| headers, to account for mis-labelled mail.
| � If the incoming message has no MIME charset, message is displayed
| according to the encoding(s) chosen for sending, cf. above, or
| on account of a suitable heuristic. Again, user can manually
| override this choice.
| � If the incoming message has an unsupported MIME charset, user
| is notified and asked to select an encoding.
|
| - In operating systems with sufficient UCS support (a UCS-aware
| plain-text editor is the treshold), the product stores copies
| of messages in a uniform UCS encoding.
So far, Qualcom has not answered to this suggestion.
Best wishes,
Otto Stolz
