Frank da Cruz wrote on 1999-08-16 17:15 UTC:
> If xterm is to handle Hebrew or other RTL writing systems, it should do so
> in the same way as the terminal it is emulating, because it's a terminal
> emulator.
I might to some degree agree with your conclusion for Hebrew (because
RTL scripts are perhaps too big a hassle in general), but I do not agree
with the more general idea that a terminal emulator should only do what
historic 1970s terminals did. There is a real need to extend and
modernize the dump VT100/ISO 6429 terminal semantics, which has proven
to be highly practical and useful, for at least some subset of Unicode,
and I personally believe that this is very feasible for
- UTF-8 (one or more bytes = 1 character)
- Asian wide characters (one character = two char cells)
- combining characters (up to say 3 characters = one char cell)
all handled according to strictly standardized algorithms that the host
application can predict easily.
And we should do this, even if there exists no real historic terminal
that provides such functionality, because the development of this type
of dump terminal predates Unicode by over a decade.
The dump terminal idea is too useful to stop any further development on
it in the Unicode age. Kermit and xterm are not just terminal emulators
any more, they are the de-facto terminals these days. So feel free to
drop some historic ballast in the form of ancient and dusty VT102-H
manuals and start to innovate. What would the VT100 have looked like if
the full ISO 10646 had been available back in 1971?
Markus
-- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:51 EDT