Some pcf fonts fail to be rendered with recent Xft releases, using Freetype
2.1.7, fontconfig-2.2.2 & xfree-4.3.0 (Gentoo revision 6). They show some
default fallback font (sans probably).
Way to reproduce, download artwiz fonts from
http://fluxbox.sourceforge.net/artwiz-aleczapka/index.php . Use the gnome font
viewer to view eg. kates (note, some of these fonts work, others don't) :
gnome-font-viewer file:///<path-to>/kates.pcf . g-f-v now segfaults. Kates is a
digit like font if you have other means of seeing it in action.
Backtrace taken from g-f-v :
(gdb) run /usr/share/fonts/artwiz-aleczapka/kates.pcf
Starting program: /usr/bin/gnome-font-viewer
[Thread debugging using libthread_db enabled]
[New Thread 1088679808 (LWP 19175)]
XftFontInfoFill: <none>: 0 (14 pixels)
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1088679808 (LWP 19175)]
strlen () at ../sysdeps/i386/i486/strlen.S:69
69 ../sysdeps/i386/i486/strlen.S: No such file or directory.
Current language: auto; currently asm
#0 strlen () at ../sysdeps/i386/i486/strlen.S:69
#1 0x400235e0 in _XftReleaseFile (f=0x810adc8) at xftfreetype.c:281
#2 0x400244ad in XftFontOpenPattern (dpy=0x805ba40, pattern=0x0) at
#3 0x0804a74c in create_text_pixmap (drawing_area=0x80ea430, face=0x807d5a8) at
#4 0x0804ba9b in main (argc=2, argv=0xbffff574) at font-view.c:452
The culprit seems to be the 1.40 revision patch of xftfreetype.c and in
particular the search for the closest bitmap size. Without this code everything
Keith referred me to
interesting, i saw that mail a couple of days ago.. never made the mental link.
Though since when has this become a problem exactly, as it turns out I was
actually running freetype 2.1.5 at the time (duh). I tried with 2.1.4 as well,
no change. 2.1.7 the same.
When i compile freetype-2.1.4 & xft-2.1.4 (xftfreetype.c:211:2: warning:
#warning using old freetype without y_ppem) it still crashes.
The problem seems to be that an XftFtInfo->file is NULL, is this ever supposed
to happen ?
Xft should "always" be able to open a font given the file name, index and pixel
size. The problem is that for bitmap fonts, FreeType doesn't do a "best fit"
match, rather it requires an exact match. Combine that with ambiguities
concerning what values you're supposed to use to match with and the result is
that sometimes Xft fails to open the font, even though it "knows" the font is
We should certainly fix that bug first by providing rasterizer and
FreeType-version specific code to pass the right size information into the library.
However, we should also fix Xft so that it doesn't crash when it can't open a
font which should exist. There are other causes for failure here; memory
issues, file system changes and permission problems. One possibility is to
insert a basic truetype font right into the fontconfig library binary and
provide a special call to access it; that would ensure that any fontconfig-using
program would always have some font it could use to recover from catastrophic
The other possibility is to have Xft handle this case internally. That will
leave us with a somewhat broken API as you'd have an Xft font that didn't have
an associated FreeType font handle; applications which today assume that these
two are tied together would be broken.
Neither is a perfect solution, but I suspect the embedded font would cause fewer
Ok, for the bitmap file issue (i.e. not some random FreeType can't open font
lossage), I think I've got a simple solution -- try both the x_ppem/y_ppem and
the width/height values and see which can open the font.
Can someone else give this solution a try (it's in CVS) and let me know if it
works now? Somehow, I'm having "issues" getting things to break today.
This solution works for me afaics.
Thanks for testing.