> Well, since today seems to be a day for mentioning products...
>
And plugging the still-current and widespread uses of terminal emulation...
> let me put in a word for RLG's implementation of Hebrew (and other scripts),
> also in an ISO 2022 environment...
>
Thanks! This is the kind of application that the public needs to be
reminded of now and then, as they tend to forget what goes on in the real
world from one week to the next if it isn't in the headlines of PC Week with
a prefix of "Hot".
> [When I last saw ALEPH it limited data in a field to Latin script plus
> one other, and AFAIK that's still the case.]
>
I'm certainly not plugging ALEPH over anything else; merely citing it as
an example of the usefulness of ISO 2022 based terminal emulation, even
for a mixed Roman/Hebrew application (one which is, indeed, bidirectional
as far as the user is concerned).
The only reason for the 2-script limitation in ALEPH is that it was
designed to work with actual Hebrew-model VT100 terminals, which
themselves had only two scripts. It is certainly not (as is evident in
your own software) a limitation of the underlying model.
Software such ALEPH and RLIN should be accessible from terminal emulators
that use standard and widely available monospaced Unicode fonts such as
Lucida Console, but I think the absence of Hebrew, Arabic and other
scripts from such fonts is due to the misapprehension that there would be
no use for them.
In fact, and perhaps somewhat ironically, the ISO 2022 model can truly come
into its own now that an increasing proportion of connections are reliable
(e.g. over transports such as TCP and X.25); there is less danger of
"noise" causing spurious state changes. (In truth, ISO 2022 is no
different from Telnet protocol, as an in-band, stateful signaling method;
but unlike ISO 2022, Telnet always has a reliable transport.)
I don't like to think that Unicode and ISO 2022 are opposing concepts. I
hope the current proposal shows how one can complement the other (e.g. in
a situation where one has ISO 2022 "on the wire" and Unicode internally):
in this situation, ISO 2022 applications actually promote the use of Unicode.
> We also support joiner and non-joiner capability (after
> Joe Becker -- I read his "Scientific American" and ACM papers).
>
I'll bet that's how many of us found our way here!
- Frank
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:42 EDT