Re: [i8n] Latin 2 fonts need modification in rootdisk.sh
> > So why isn't "consolechars --font FONT --acm iso02", where FONT is a
> > PSF font that includes a _correct_ SFM, a workable solution?
>
> Because the ACM selection is VC-specific.
This is, indeed, an inconvenience, but not a disaster.
> To demonstrate: after doing what you suggested, the user switches to
> another virtual console. The font won't display correctly anymore
> because the kernel is still using the default (ISO 8859-1) ACM for
> that virtual console. (The standard workaround is to put "printf
> '\033(K'" (which selects the user-defined ACM) in /etc/profile.
> However, if the user runs "reset", things are wrong again.)
The obvious solution would be to redefine "reset".
> > By the way, if the current hack works, I recommend not changing it in
> > potato. I can live without UTF-8 in the installation system. But I
> > would be opposed to a font with an incorrect SFM going into
> > console-data; iso*g.psf should be packaged as part of boot-floppies
> > and come with a prominent health warning.
>
> I think this "incorrect SFM" is very useful, so I don't see why it
> shouldn't be provided as a part of console-tools.
If the SFM is provided separately, I suppose I might not complain. But
please don't supply a PSF font with an included SFM that is incorrect,
because it would cause massive confusion to anyone who wants to either
use UTF-8 or use the font in conjunction with an ACM.
Some hapless person might even try "consolechars --font iso02g.psf
--acm iso02" and have a nasty surprise ...
It's not even necessary to supply the hacked SFM with console-tools.
Instead you could supply a recipe/script that takes as arguments a PSF
font with a correct SFM and an ACM, and outputs a hacked SFM that
combines the SFM with the ACM. Doesn't that make more sense?
> > And probably we should do something different in woody.
>
> Like what? A less-limited kernel console driver?
I'm not sure. I expect there are already plans. One possibility would
be to ignore the kernel console driver and use a user-space program
instead. You need that for Chinese, Japanese, Korean, etc anyway, so
you might as well have all languages using the same user-space program
with UTF-8, wide characters, etc. I have a version of slang that runs
in a UTF-8 xterm. I use it with mutt for reading e-mail; it's nice to
see Russian, Chinese, etc all working properly with no
language-specific hacks required ...
Edmund
Reply to: