I tried to reproduce this bug, but my X server never crashed. Instead
it always freezed and forced me to press the Reset-button of the
computer.
I discovered that the bdf-fonts that cause this behaviour (package
xfonts-cronyx-misc, version up to 2.3.8-1 -- these are ISO10646-1
fonts) did't have DEFAULT_CHAR. When I added DEFAULT_CHAR to them the
problem disappeared.
The fonts from the packages xfonts-cronyx-{cp1251,koi8r,koi8u,isocyr}-misc
are the same but in eight bit encodings and they didn't caused any
problems. I also noticed that the font tixus.bdf doesn't have
DEFAULT_CHAR and its encoding is ISO8859-1 (i.e. eight bit).
After I made new packages with DEFAULT_CHAR in all fonts and I
installed the new package I was not able to reproduce the bug anymore
even if I added a directory with the old fonts to the font path. This
means that the bug is not always easy to reproduce.
The bug doesn't depend on whether I use font server or not.
fstobdf generates fonts with DEFAULT_CHAR 0. I don't know if this is
the supposed behaviour; these fonts don't include glyph with code 0.
I will upload the new packages and ask Alexandra Kossovsky if she can
reproduce the bug with the new fonts.
I found this in the package xspecs:
Properties named FONT_ASCENT, FONT_DESCENT, and
DEFAULT_CHAR should be provided to define the logical
font-ascent and font-descent and the default-char for
the font. These properties will be removed from the
actual font properties in the binary form produced by a
compiler. If these properties are not provided, a com-
piler may reject the font or may compute (arbitrary)
values for these properties.
According to this the compiler is supposed to deal with such fonts.
In my case bdftopcf didn't reject the fonts and didn't compute any
value for DEFAULT_CHAR. This means that bdftopcf is also responsible
for this bug.
Anton Zinoviev
