> Hmm - the translation is set to LAT1_MAP, but it would be
> too optimistic to associate that with Latin-1 (ISO-8859-1).
> So, maybe it does not matter. As we just learned, one can
> work fine with this translation and a Latin-2 font,
> provided one kills the unicode map.
Unfortunately it's NOT fine.
The physical font doesn't need and even shouldn't be in ISO-8859-2 order,
because about 2/3 of box drawing chars must be in the range C0..DF (these
chars are not in ISO-8859-2, but with proper unicode map they can be used
if an application switches the charset to VT100 graphics or CP-437).
One can make a font with ISO-8859-2, additional punctuation of CP-1250,
VT100 graphics and anything else. With proper Unicode map such font can be
used as any character set and as Unicode as well. For example an email
program could see that a letter is in ISO-8859-1 and set ACM to ISO-8859-1
leaving the translation to the screen font for the kernel - then for
example German would look OK and some French letters would only loose
their accents. And one font can be used as both ISO-8859-5 and KOI8-R.
One ISO-8859-2 font common in Poland does have a unicode map. This map is
fake: for example the character "C with acute", which has the unicode
U+0106, is described as U+00C6, because in ISO-8859-2 it has the code
0xC6. Such font can't be used in Unicode mode (unless we load an
additional, this time real Unicode map).
So my fonts have proper unicode map and this map is being used. Everything
works fine and the _only_ problem is that resetting the console switches
the ACM to ISO-8859-1. Very stupid problem, isn't it. The fix will be
small and correctly mapped fonts will become fully usable.
--
QRCZAK #
__("< Marcin Kowalczyk #*#
\__/ qrczak@knm.org.pl #\#&#
^^ http://qrczak.home.ml.org/ I