> I thought that would be one feasible way. Note that MS-DOS/CGA has even
> graphical characters in the CL range. We certainly can't support these
> in the Cl range, but they could be mapped into the CR range for
> instance. I'm note sure myself however, whether that is really worth the
> effort of revision ISO 2022.
Access to these characters is provided by a proprietary escape
sequence on some terminals.
> > The only possible scenario that I can see is the use of ISO2022
> > escapes which would disable the use of ISO2022 until a suitable return
> > sequence is issued. This may be suitable for some applications.
>
> Agreed.
>
> > However, I believe it will break most terminfo/termcap entries that
> > assume ISO2022 is used for box drawing.
>
> Just like UTF-8 does. There are already applications around that
> deactivate the DEC block graphics in UTF-8 locales and use the U+25xx
> codes instead. W3m-m17n <http://www2u.biglobe.ne.jp/~hsaka/w3m/> is a
> very nice example that makes good use of UTF-8 block graphics when in
> UTF-8 mode. Absolutely don't use any terminfo/termcap entries for block
> graphics when you are in UTF-8 mode!
As long as ISO2022 is not in use when a non-compliant character set is
in use, I am in complete agreement.
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/lists/
