Messages in this thread | | | Date | Tue, 2 Feb 1999 01:59:26 +0100 (MET) | From | (Guest section DW) | Subject | Re: Unicode console patch |
| |
From: "H. Peter Anvin" <hpa@transmeta.com>
Well, as I said -- I'm trying to revisit all of these, especially the currently broken handling of G0, G1, G2, G3 and the other ISO 2022 issues.
Just as a proof that the current Linux console is broken,
Well, broken - it implements a vt100-like terminal, with some features that remind one of ISO 2022 but are not the same.
The Linux version is documented in the kbd-FAQ. The ISO 2022 version is documented in the charsets(4) man page.
It would have been nicer if they had been the same. As it is, I am not quite sure whether many people need strict ISO 2022 compliance. (And this strict compliance can be obtained in user space by an application interpreting the received escape sequences and doing the appropriate corresponding Linux things.)
Linux considers 8-bit character sets to be atomic, rather than composed of two 7-bit character sets, which is the ISO 2022 model.
Yes. I remember from the good old times that I had some disagreements with Mike Jagdis about this stuff.
The question is whether one wants a console that is completely flexible, in principle also able to handle EBCDIC or Code Page 1234, or do we want to stipulate in advance that the console must implement ISO 2022 ? For Linux, where many people live close to a DOS world, the single character set model may make it easier to interface with DOS things.
I am not really voicing an opinion now, just saying that when there are so many standards to choose between, it is not immediately clear that we want to pick ISO 2022, which is semi-superseded by ISO 4873 and will be made obsolete by ISO 10646.
Andries
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |