% setfont iso02.f16
Now the text is shown correctly, but cut-and-paste picks
incorrect characters. Maybe because I didn't load a unicode map.
% setfont iso02.f16 -u iso02
Now everything is wrong.
% setfont iso02.f16
Now everything works. Interesting...
What happens? Well, con_write(c) does
tc = translate[c];
tc = conv_uni_to_pc(tc);
if ( tc == -3 ) /* bad hash table */
tc = c;
and then tc is written in screen memory.
After the "setfont iso02.f16 -u iso02" the unicode map is filled
correctly, but the "translate[c]" is still the identity map (LAT1),
so "conv_uni_to_pc(tc)" cannot find these Latin-1 characters, and
all is wrong.
But after the "setfont iso02.f16" the unicode map is invalidated
(hashtable_contents_valid=0), and "conv_uni_to_pc(tc)" returns -3,
and c itself is written to the screen, which happens to be correct
for these iso fonts.
What about the pasting? Well, the inverse mapping was filled
correctly by the "setfont iso02.f16 -u iso02" and not destroyed
by the "setfont iso02.f16".
Thus, the conclusion is that if one wants to use Latin-2 on
the console, without going into UTF-8 mode, then
setfont iso02.f16 -u iso02; setfont iso02.f16
works well (by making sure that the kernel's unicode tables
are not used).
So, it looks like the console is broken for non-UTF-8 mode
when one uses anything but Latin-1 (or sets straight-to-the
font mode, e.g. by printing `ESC ( K').
In the good old days things used to work, I think.
Comments? hpa? Anyone who uses Latin-2 daily instead of once a year?
Andries
[this was 2.0.33, but I suppose things have been like this since
1.3.1 or so]
[I do not read linux-kernel; please cc to aeb@cwi.nl]