I think this is a bit overboard. As far as I can tell, the issue is determining
the subset of Unicode characters is that can be supported in a terminal
environment. Moreover, all the problems I have seen mentioned here are in fairly
specific instances, and might cause specific restrictions (like with the letters
in "login: ") that people may be able to live with. For example, people could
probably live with single-key menu selections being limited to base characters,
no matter what the script.
Mark Davis, IBM Center for Java Technology, Cupertino
(408) 777-5850 [fax: 5891], email@example.com, firstname.lastname@example.org
Paul Keinanen <email@example.com> on 99/09/30 02:03:33 PM
To: "Unicode List" <firstname.lastname@example.org>
Subject: Re: Matching Unicode strings and combining characters [was: basic
On Thu, 30 Sep 1999 11:50:28 -0700 (PDT), Geoffrey Waigh
>Paul Keinanen wrote:
>> So Unicode is not supported in a real time environment ?
>I did it several years ago. It is much easier when you accept that most
>of the complexity in Unicode is there for good technical reasons and to
>work with it rather than twist it to fit old ASCII programming practices.
This is hilarious.
So the following are "old ASCII programming practises" that should not
or can not be used with Unicode:
- any use of asynchronous lines (except PPP+HTML)
- any use of hardcopy terminals
- keyboard entry with remote echo over serial line or telnet
- single key menu selections over serial line or telnet
Apparently the only communication environments in which Unicode works
without problems is (IBM mainframe style) block mode terminals and in
HTML (the CICS of the 90's :-) and of course ftp and other file
Call me old fashioned, but I think these restrictions are quite
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:53 EDT