Re: Unicode console patch

Guest section DW (dwguest@win.tue.nl)
Wed, 3 Feb 1999 20:45:44 +0100 (MET)


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/