Messages in this thread |  | | | From | Alexios Chouchoulas <> | | Subject | UTF, console.c and ASCII 155 | | Date | Sun, 16 Feb 1997 03:44:12 +0200 (EET) | |
Greetings.
This is a query about relatively recent kernels. My sincere apologies if
this is a FAQ or it deserves instant flaming to hell and back. :-/
Could someone please explain the rationale behind hardwiring ASCII 128+27
to be equivalent to ASCII 27 (ESC) in drivers/char/console.c? I know it's
the standard thing to do, but why can't it be turned off?
Let me explain. Around line 1446 of drivers/char/console.c, we have
ok = tc && (c >= 32 ||
(!utf && !(((disp_ctrl ? CTRL_ALWAYS
: CTRL_ACTION) >> c) & 1)))
&& (c != 127 || disp_ctrl)
&& (c != 128+27);
This determines if a character is printable or has to be interpreted as
some sort of action. Out of all characters in the 8-bit ASCII table, only
character 128+27 is treated specially: the glyphs at ALL other positions can
be printed, even the one for 27 (ESC). Why not the one for 128+27?
The reasoning behind this question is that one particular national
language encoding (Greek code page 737, gradually being phased out by
ISO-8859-7 but still used by companies and a lot of BBSs alike) loses quite
an important glyph (lower-case delta) because of this.
There seems to be no other way for this to work besides a kernel patch and
the whole point is that a lot of the people I support don't want to do this.
Thanks,
Alexios
--------------------------- ,o88,o888o,,o888o. -------------------------------
Alexios Chouchoulas '88 ,88' ,88' alexios@vennea.demon.co.uk
The Unpronouncable One ,o88oooo88ooooo88oo, axc@dcs.ed.ac.uk
|  |