Re: Linux i18n project coordination

From: Markus Kuhn (
Date: Sat Aug 14 1999 - 04:17:20 EDT (Raphael Finkel) wrote:
> With regards to Linux and unicode:
> I downloaded the newest source for xterm (version 112) and compiled it with
> the unicode extension. I also got some Unicode fonts from

The latest versions of the xterm fonts are available from

> The medium news: Not all the 20 or so fonts in the package contain the Hebrew
> region, and of those that do, most either are missing the vowels (we need
> komets, pasekh, and khirik for Yiddish) or the special Yiddish characters
> (tsvey-vov, vov-yud). However, two of the fonts appear complete in that
> regard:
> -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1
> -misc-fixed-bold-r-semicondensed--13-120-75-75-c-60-iso10646-1

The good news:

You are more than welcome to contribute the remaining missing
characters. Check the README file in

for details of how to contribute. (In a nutshell: Just install xmbdfed
from <>, study the style and
dimensions of the existing characters in the font, add the missing
glyphs, and send me a "diff -u" patch of your changes on the BDF file).

I also appreciate any constructive (= diff -u) feedback on the quality
of the Hebrew glyphs in -misc-fixed-*-iso10646-1, because some of these
were drawn by contributors who are not very familiar with Hebrew

> The bad news: xterm has no facilities for right-to-left, so you need to
> reverse your text manually (or learn to read backwards). xterm has no support
> for composing characters, so even if you get pasekh-alef, the pasekh will
> follow the alef, not be composed with it.

The good news:

The lack of support for composing characters might eventually be fixed.
I've discussed this already with the xterm maintainer Thomas Dickey
<>, and he said that though it would not
be easy given xterm's existing internal structure, it is but probably

The bad news:

The lack of right-to-left support will probably not be fixed in the
foreseeable future, because nobody has been able yet to explain to us
how *precisely* this should work and interact with the many editing
control sequences supported by a VT100 emulator. We don't have any idea
or reference implementation of a VT100 emulator that does bi-di support
in an adequate way. So the current approach is that the application has
the responsibility of reversing the Hebrew characters in any output. See
for example <http://> for a
library that does this for you and that could be integrated into file
content viewers such as "less". For a more detailed discussion of these
issues, please read

In the -misc-fixed-*-iso10646-1 project, we have set up several target
repertoires that we want to complete with some types of fonts. If you
give me a list of the Unicode numbers of the characters that you need
for Yiddish, I would be able to add them to the TARGET3 repertoire.

Please note that the -misc-fixed-*-iso10646-1 fonts are so-called
CharCell (C) fonts, that is, no ink is allowed outside the bounding box
of the character and all characters have equal width. This is the type
of font requires by xterm and emacs. In addition, any combining
character support that might be added to xterm will only be a simple
overstriking (logical OR or pixels) of the base glyph with the combining
glyphs, because BDF fonts do not contain any auxiliary information of
accent alignment. While this will not lead to satisfactory results for
Latin combining characters above, it should work nicely for Thai,
Hebrew, Navaho, most IPA, and a number of other scripts and languages
that depend on combining characters.


Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at,  WWW: <>

This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:51 EDT