Re: Linux console fonts

[Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk>]

Andries.Brouwer@cwi.nl wrote on 1999-08-30 08:07 UTC:
> Is there a standard solution in the X world?

Not at the moment. There are rumours about a font working group at
X.Org, and that's all I know.

> If this is an unsolved problem, I imagine I'll change
> the format of the Unicode table attached to psf console fonts
> so that it can have a sequence of Unicode values attached to
> a single glyph [not as alternatives, like today, but as base
> symbol followed by combining accents].

This seems the way to go, and the OpenType font format specification has
also been extended by similar mechanisms. You might want to have a look
at how Adobe/Microsoft/Apple use ligature mechanisms to handle these
cases.

http://www.microsoft.com/typography/tt/tt.htm

> This would allow one to use the kernel as rendering machine
> in all simple situations, namely where a precomposed form is
> already available in the font.

It is quite feasible to implement all this for the case, where the
terminal just outputs a continuous stream of Unicode characters, and I
guess the mechanisms required in this case are fairly well understood
now. The more problematic aspect - and this is where it becomes a bit of
a research problem - is how these rendering algorithms should act if the
Unicode sequences sent to the terminal are mixed with cursor-control and
editing commands, as they are in a typical vi session. Will vi have to
fall back with sophisticate scripts like Arabic and Devanagari into a
mode, where it always repaints almost the entire line, to create for the
terminal the necessary contect to cause the right glyph ligature to be
selected? How shall the terminal behave to preserve the non-displayed
state that has to be kept between two write() calls where you want
already to display as much as possible, but where later added characters
can change an already written glyph? E.g., think not only about
combining characters, but also about Arabic final forms that become
middle forms if you add another character without a space.

All this goes far beyond what I had in mind for xterm in the nearer
future (where we are limited by what BDF fonts can do), but it is
certainly an exciting idea to start tacking advanced Unicode rendering
for Tibetian, Devanagari, Arabic, etc. in the console as well. One
essential mechanism is an automatic ligature glyph substituter and
associated information in the fonts. The fact that we have in the
console better control over the font file format will be of great help
here. The other main issue will be bidi output for Hebrew and Arabic.

Markus

-- 
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>

-
Linux-UTF8:   i18n of Linux on all levels
Archive:      http://mail.nl.linux.org/lists/