Re: [i8n] Latin 2 fonts need modification in rootdisk.sh

[Edmund GRIMLEY EVANS <edmundo@rano.org>]

> > > > 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.

You keep saying that, in various formulations. You never explain why.

> > > 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.

You make "reset" a script that does what standard "reset" does and
then selects the user-defined ACM. Why does this require changing the
kernel? Why should I even want to change the kernel?

> > 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.

Since it's easy to recompute, I'd rather not waste disc space on it.

> > > > 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.

Yes, we might have to wait till whatever comes after woody, or even
the one after that. It really depends on what the Chinese, Japanese,
Koreans, etc, want. If they want to continue using language-specific
encodings for a few more years, then they can, of course. But
eventually they will move to UTF-8 and I prefer to join them at that
point rather than continue to suffer the inconveniences of 8-bit
charsets.

Edmund