RE: Compatibility with Unicode

[dank@blacks.jpl.nasa.gov]

Masataka, thanks for your answer.

I wrote:
> [Because Unicode is being incorporated into major OS's,
>  we should choose a character set that is a simple extension of Unicode
>  such that no huge lookup table is needed to map between them.]

Masataka Ohta wrote:
> [The space required for fonts is larger than the space needed by a
>  lookup table, so why worry?]

There is a lot of software which deals with text but doesn't need to
display it.  For instance, Perl programs (e.g. several of the whois++
servers) operate on text without managing its display on a CRT.
It would be nice if one could write a function to convert to Unicode
in Perl without having to lug a megabyte table around.  It certainly
would make things easier for the little guy.

> But many poeple can't understand even such simple calculation, simple
> rule is better to avoid stupid debating.
It's always better to avoid stupid debating!  But the people on this
list aren't stupid, even if they do have trouble communicating sometimes.

> [ My proposed ICODE is roughly UNICODE extended with five more
>   bits to handle five flavors of Han (3 bits) plus missing Han characters
>   (1 bit) plus bidirectionality (1 bit). ]
Did I summarize you correctly?
This sounds good- are you really saying that one can convert half of the ICODE
characters to UNICODE by throwing away the upper five bits, at the cost
of losing information about the 'dialect' of Han and the 'bidirectionality'?
And that UNICODE can be converted to ICODE by adding five bits of zeroes?

I must confess, I am still uncertain what the 'bidirectionality' information
is that you want to encode with that extra bit is.  Is it the direction
(left->right or right->left) that the character is normally written with?
Dan Kegel