Also would be very expensive in terms of kernel memory.
> > Perhaps a new console sequence to reset the fonts.... either that or only
> > the font-set sequences be able to reset the font.
>
> Maybe.
>
> > Uhmm... Loading/unloading fonts is ioctl, right? <sigh> - this makes it
> > REALLY hard to emulate console under, say, X (I _REALLY_ don't like
> > Xterm's keyboard/display/font mapping).
>
> Yes, it's hard to emulate, but I know of no better way how to do it.
Well there is escape sequences (very easy to emulate, works across
telnet etc.; disadvantage: makes it easy to utterly scramble someone
else's console.) That is a reasonable thing to do if it is
per-console.
If we want a more "out-of-band" solution I suggest creating a
libconsole which maps to ioctl() for the kernel console; X and other
user-space solutions can use sockets or X resources or whathaveyou to
communicate. This separates the API from the IPC method used.
> > I think the latin-1 centeredness is from having 4 pages of maps: (AFAIK)
> > 1 - default latin-1
> > 2 - graphical mapping
> > 3 - IBM-PC mapping (for hysterical raisons :)
> > 4 - userspace font
>
> Yes. The IBM-PC mapping is not for HR only, it's currently the
> only way how to extend the VT100 graphics to something more usable.
>
> 5 - UTF8.
UTF-8 is not a map; it plugs directly into the Unicode layer. The
8-bit maps are maps from 8-bit charsets to Unicode.
> > VGA/text can handle up to 512 characters (some can handle more though -
>
> Yes, but at the expense of having only 8 background colors.
YM "foreground" HTH.
> The kernel should surely use only ASCII for its messages and the Latin-1
> set should be only a default setting of the translation tables, but they
> must be fully reloadable by user programs.
Actually, the Latin-1 table in the kernel, selectable with ESC ( B is
fine, but the ISO 2022 codes for other charsets should be honoured,
and Latin-1 shouldn't be the automatic default.
-hpa