Messages in this thread | | | Date | Wed, 3 Feb 1999 20:45:44 +0100 (MET) | From | (Guest section DW) | Subject | Re: Unicode console patch |
| |
From: "Stanislav V. Voronyi" <stas@cnti.uanet.kharkov.ua>
In message <199902020029.BAA23462@wsdw01.win.tue.nl> Guest section DW writes:
> From: "Stanislav V. Voronyi" <stas@cnti.uanet.kharkov.ua>
> \033(? - ask about G0_charset > \033)? - ask about G1_charset > \033%? - ask about utf state > \033C - ask about charset (^N/^O) > \033? - ask about all together > The response string is the escape sequnce to set appropriate mode, i.e. > \033(? -> \033(K or > \033? -> \033(K\033)0\033%@^O > So now possible send to console \033?, save the response string, and than > just send saved string to console to restore its state. > Is this sequnces good ? Any comments wellcome.
>No, these sequences are no good. >Instead of describing the structure involved, let me point you at >the references. Most relevant are ISO 2022, ISO 4873 and ISO 6429 >which are freely available as ECMA-35, ECMA-43 and ECMA-48. >See http://www.ecma.ch/stand/ecma-035.htm and >http://www.ecma.ch/stand/ecma-048.htm .
Well, I looked through all this standarts & did not found anything about REQUESTING from terminal about its codepage set or is terminal in UTF mode or not.
Probably you want to use the Device Status Report: ESC [ n (or the Device Attributes request: ESC [ c). Private extensions belong to ESC [ ? ... You may want to look at ctlseqs.ms or so, describing the xterm setup (which uses ESC [ ? 1000 h and similar to report mouse position, I think).
Of course, using such stuff is a bit difficult: the program outputting stuff to a console may not have access to the input side (as in a pipe prog1 | prog2 | prog3 where the user types to prog1 and prog3 produces the terminal output - even if it asks a report, for example whether UTF8 is in use, it may never see the answer).
Many programs do a `save status' at the beginning, and `restore status' at the end, and do what they want in between.
Imo all this standarts too old and does not apply to real life. For instance no one of this standarts does not have any smalest word about KOI-8[RU], or about UTF-8 mode.
I agree with the first sentence. But it is not the job of these standards to talk about specific character sets. The Registry, set up in accordance to ISO 2375, describes hundreds of character sets.
Imo the worst thing it said "linux console broken" and do nothing.
But it is not broken [well, yes, I know about lots of bugs, but not broken in the sense as discussed here]. It just does not follow all ISO 2022 rules. (And even if we would fix the character set stuff, which might be a bad idea, then there would still be other parts of ISO 2022 that we don't follow.)
If possibility to get console translation modes will not be included to 2.2 kernel we stay in situation without UTF support untill 2.4 will be released. Imo it the worst case.
Possibly. But I would prefer things just the other way around. If people write interesting software, that we all want to use, and it requires a little bit of kernel support, then that little bit of support is easily added. But just adding some support fragments, without having a grand design, with no such software in existence, is just adding ugly warts to the already not so pleasant console driver.
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/
| |