Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk> writes:
> Unicode can only reasonably be supported under VT100-style terminal
> emulators such as xterm or kermit in the UTF-8 encoding. With "Unicode"
> as opposed to UTF-8, I assume that you mean UTF-2 or UTF-16, i.e. a
> steam of 16-bit character values. Since VT100 terminal interfaces are
> inherently 8-bit blocked, using raw 16-bit values would create
> synchronization hazards and would also create very severe
> backwards-compatibility problems.
This is certainly true. Beside, using Unicode should be out of
question anyhow. We really should not start handling these horrible
surrogate characters.
> I hope that eventually xterm can be started with some "-utf8" option and
> then the displayed text will be interpreted as UTF-8, the keyboard
> generates UTF-8 codes, and cut&paste functions will operate with UTF-8
> as well.
I'd suggest to use escape codes to do soft-switches.
> None, except for a few character set conversion tools, most of which now
> also offer UTF-8 processing (e.g. the GNU recode beta prereleases on
> <http://www.iro.umontreal.ca/contrib/recode/>).
iconv from glibc 2.1 will be installed everywhere and also has these
capabilities.
> Exact same dream here. However, first of all xterm has to be made UTF-8
> aware, because all the other tools depend on it in daily use, then we
> can see further. We should try to get a decent UTF-8 -> TeX and
> UTF-8 -> LaTeX converter into GNU recode to do the preprocessing
> you suggested.
Is this at all necessary when you use Omega?
-- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:44 EDT