> Frank - I understand your concerns. But one way of looking at what we
> need is some tagging format possibly used in ACAP and IMAP, which MUST
> not leak to other places. And what you probably worry about is the C1
> area in terms of octets (which is already gone with UTF-8) and not the
> C1 character space in Unicode, which turns up as two bytes in UTF-8.
>
This sounds reasonable, but nevertheless I don't think much (or any)
thought has been given to Unicode in a terminal-to-host setting, and so
who is to say what form traditional control characters, control sequences,
and escape sequences would take in a "Unicode terminal"? Would it use
octets or hextets? I'm not arguing against anything in particular, but I
am (as always) arguing in favor of NOT structuring Unicode in a way that
locks out time-honored applications.
For example: Look at EMACS. Then look at MULE -- all of the horrendous
complications caused by ISO 2022 character-set designation and invocation.
This is nothing against MULE -- it's a magnificent achievement, and the
massive amount of work that has gone into it has shown that there is a
great demand for multilingual platform-independent plain-text in the
terminal-to-host setting.
Now contrast MULE with a hypothetical Unicode-based EMACS. Isn't one of
the goals of Unicode to "stamp out ISO 2022"? :-)
- Frank
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:34 EDT