Re: [i8n] Latin 2 fonts need modification in rootdisk.sh
On Tue, Feb 29, 2000 at 07:00:52PM +0000, Edmund GRIMLEY EVANS wrote:
> > > 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.
>From the boot-floppies point of view, it's much closer to a disaster
than to a inconvenience if you want to use ACM's.
> > 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".
No, not really.
I'll just point out that redefining "reset" in such a way that it
doesn't reset the ACM requires changing the Linux kernel. If you
want to change the Linux kernel, please discuss your ideas on the
linux-kernel mailing list. Thanks.
> 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.
Note that the isog package, which you're already familiar with,
already provides a separate font, and a separate SFM.
> 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?
Of course. A similar script is in the package since its inception.
> > > 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 ...
I don't think you're going to see UTF-8-based boot-floppies in woody.
Reply to: