> DEC terminals only have keyboards for input. These are harmless, because
> only a very simple character repertoire can be produced on them.
> Terminal emulators have a far more powerful input device: cut&paste
> selection from other applications, sophisticated input methods for
> languages not covered by a single GR set, etc.
>
> I'm not sure, whether DEC practice scales well here. (Actually, the only
> thing that scales well is stateless UTF-8 everywhere, but doesn't help
> Juliusz who seems to want to write an ISO 2022 terminal emulator, but
> probably should just stick to a slightly extended kterm emulator.)
The issue is the following:
make sure that all data sent from the terminal is transmitted in the
character set expected by the host application.
At the current time, host applications only expect the data it
receives to be in a single character set. That is the character set
determined by the currently configured Locale. It is the
responsibility of the terminal to convert from the local input
character sets to this remote input character set regardless of the
input source (keyboard, clipboard, ...) The terminal must know what
the character set of the input is in order to perform the conversion.
In the DEC VT terminal, the Keyboard Language always matches the host
Locale. In Kermit, we convert from the local keyboard and clipboard to
the Keyboard Language before sending the data to the host.
If the Keyboard Language is ISO Latin1 and the clipboard contains
Unicode data containing Cyrillic, then there is a lossy translation.
If the Keyboard Language is UTF-8, then there is no loss at all.
Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available
The Kermit Project @ Columbia University includes Secure Telnet and FTP
http://www.kermit-project.org/ using Kerberos, SRP, and
[EMAIL PROTECTED] OpenSSL. SSH soon to follow.
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
