Re: FreeBSD i18n fonts for wscons

[uwe%stderr.spb.ru@localhost (Valeriy E. Ushakov)]

Matthias Drochner <M.Drochner%fz-juelich.de@localhost> wrote:

> [from Lubomir's article]
>> Add a line for that font to wscons.conf(5)
>> font  latin2  -  16  iso  /usr/share/wscons/fonts/isolat2.816
> 
> Well, this is a hack. A harmless one, and this has been done
> before, but it is still a hack. What this does is to load a latin2
> encoded font but pretends that it is an "iso" one (which
> means latin1). It leads to the desired result because the
> vt100 emulation just maps chracters 128..255 to the corresponding
> ISO font positions (following the behavior of a real VT100).
> Loading another font as "iso" changes the visual representation
> behind the vt100's back.
> 
> There is nothing like a "wscons encoding". It is the terminal
> emulation which controls how sone incoming byte is supposed
> to look like on the screen.
> 
> What you want is obviously a terminal emulation which does all
> the ANSI escape sequences like a VT100, but maps the upper 128
> characters in a user defined way. This shouldn't be hard
> to do, and it could share a lot of code with wsemul_vt100.
> It just shouldn't be called "vt100".
> 
> Valeriy E. Ushakov wrote:
>> Our font code is rather convoluted. See the funny wsfont_map_unichar
>> and pcdisplay_mapchar dances.
> 
> It is rather easy if you understand the idea: The terminal
> emulation says how the character should look like. It does so
> by passing a font independant name (which is a 32-bit value
> derived from unicode, but it is just a kernel internal value,
> so this doesn't matter) to the graphics driver. The graphics
> driver selects a glyph among the fonts it has to its disposition.
> There can be multiple matches, that's why there is some
> "best fit" selection. The driver returns an opaque index back
> to the terminal emulation, and that one is used later at runtime
> for character display.
> 
> So the idea is that whatever a user loads by "wsfontload", it
> just builds a pool where the graphics driver can pick glyphs
> from. There is no policy involved.
> The policy comes from the terminal emulation, and that's why
> a real solution should start there.

Loadable fonts worked just fine on real vt220.  I still have
collection of koi8 fonts for various fonts sizes somewhere (real dec
vt220, tatungs that emulated vt220 but had taller glyphs, etc).  IIRC,
for vt220koi8x10.h I got cyrillic chars from one of them.

vt220 didn't care about actual glyphs there.  You just loaded a font
for your national C1 separately and it was up to you to ensure it
matches the output you expect.

wsemul doesn't provide the G0..G3 distinction so wsemul_vt100 has to
go through wsdisplay_emulops::mapchar to get font indices for DEC
special graphics (i.e. ~= box/line drawing) and DEC technical charsets
from the underlying graphics driver (cf.  vt100_initchartables() in
wsemul_vt100_chars.c).  So far so good.

Then it does

        for (i = 0; i < 128; i++)
                (*edp->emulops->mapchar)(edp->emulcookie, 128 + i,
                                         &edp->isolatin1tab[i]);

and this is precisely why people just lie to it and say their national
font is "ISO" (read: "just f*ing leave C1 alone").

The alternative is to define a new font encdoing and provide
(hardcoded!)  conversion tables that first map national charset C1 to
unicode and then another conversion that effecitively maps unciode
back to C1, where it all started in the first place!  That just
doesn't scale.

I've tried to add koi8-r support back in 2001, even found and fixed a
bug in the mapping dance done by wsfont.c:

  revision 1.20
  date: 2001/06/12 00:57:10;  author: uwe;  state: Exp;  lines: +3 -3
  In wsfont_map_unichar: when checking that 'lo' is within 'map2' range,
  compare 'lo', not 'hi' (only partially edited cut-n-paste it seems).

but I never committed anything because I couldn't look at that useless
recoding dance without digust and I never actually got around to try
to unbreak it so that you don't have to hardcode recoding tables in
the kernel.

While the idea of the char mapping as used by vt100 emul is nice, the
actual implementation is quite impractical, and evidence of 15+ years
without properly localized console (compare with FreeBSD which had it
all this time) is totally irrefutable argument.

PS: Oh, and don't get me started about the keyboard side of things.

SY, Uwe
-- 
uwe%stderr.spb.ru@localhost                       |       Zu Grunde kommen
http://snark.ptc.spbu.ru/~uwe/          |       Ist zu Grunde gehen