tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: FreeBSD i18n fonts for wscons

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

best regards

Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt

Home | Main Index | Thread Index | Old Index