Fonts for console/fb for various locales: a proposal

[tlaronde%polynum.com@localhost]

Abstract: When using a console/fb outside of a whole graphical system,
the fonts available do not cover a wide range of locales. Indeed, all
the pieces exist, under a BSD compatible license, to create easily a
wide range of fonts from an existing set of libraries of glyphes. This
names the pieces; explains what has to be assembled; and ask if it is
worth the effort to do so...

1. An integer is finally converted to an indice in a font that is simply
a library of pictures to designate what has to be drawn on the terminal.

Depending on the locale used, the fonts available are whether not
totally compatible with the locale (ex.: using a latin1 font with a
latin9 locale), or don't have the corresponding glyphes, or simply don't
exist for the locale.

The problem is then:
	a) To have a set of pictures (glyphes) available covering as much as
	possible the most widely used languages. These pictures, in order
	to accommodate for various sizes, have to be in vectorial
	description;
	b) To have a mean to assemble the glyphes and even to combine the
	glyphes (for example in order to obtain an accented letter,
	combining the base letter and the accent) into a font;
	c) To process the font so that a rasterized version is obtained;
	d) To translate the result in a format compatible with the driver is used.

In fact a, b and c already exist. And d is a trivial part. The main job
is putting the pieces together.

2. The fonts (a). Amongst the available fonts in vectorial format are 
the ones described in D. E. Knuth's METAFONT language. But these do
cover the occidental latin based language, plus Greek.

A wider source of fonts, in a format that can be translated to METAFONT
easily, are the so-called "Hershey fonts".

Contrary to what could be, at first, deduced from the name, Dr Hershey
is not the _designer_ of the fonts but the one who takes a huge amount
of time digitizing in high resolution a very wide range of existing
fonts, covering occidental latin in a wide range of shapes (including
cursive, italic), but also cyrillic, greek, gothic and japanese (Kanji,
Hiragana, Katakana).

	=> The glyphes in the Hershey fonts are not organized according to
	UCS, even not to ASCII for the corresponding glyphes. If assigning
	an UCS codepoint to the latin, greek, gothic and cyrillic glyphes is
	easy, help to assign correct UCS codepoints to the japanese glyphes
	would be needed.

Side note: the caracteristic of the Hershey fonts are that they are in
vectorial format but using only polylines. They were widely used in CAD
because it is trivial and fast to scale and rotate text in such a
description and this allowed to bypass the inability of the graphical
system to scale and rotate the fonts.

So the source fonts do exist. And the license are compatible with BSD.

3. Combining glyphes (b). This does already exist in D. E. Knuth's
typographical system. This is called "virtual fonts". One can arrange
glyphes from other fonts in whatever order, combine glyphes to obtain
another one, and take glyphes from differing fonts.

A text language for description of the virtual font is available from
which can then be converted in files that are used by TeX on one end,
and the dvi drivers on the other.

The main work would be to implement the program creating a real font
from the description (the work is indeed done by the dvi drivers at the
moment).

4. Rasterizing (c). This is the whole purpose of METAFONT. METAFONT is a
rasterizer.

5. Converting to whatever format expected (d). Not a problem, and not
the problem.


Conclusion: do you think that it is worth the effort?

At first, I plan to resurrect the Hershey fonts, to convert them to
METAFONT and to then publish the rendering of the fonts. I then will
need help for the japanese glyphes (to assign UCS codepoints).

The D. E. Knuth's TeX and al. system used is kerTeX, my own distribution
of TeX and al. (http://www.kergis.com/en/kertex.html). It is under a BSD
like license for my contributions (D. E. Knuth's work has its own
license). And the development added to achieve the goal will be in this
same kerTeX license.
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                       http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C