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 /usr/share/fonts/artwiz-aleczapka/kates.pcf [Thread debugging using libthread_db enabled] [New Thread 1088679808 (LWP 19175)] XFT_DEBUG=1 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. in ../sysdeps/i386/i486/strlen.S Current language: auto; currently asm (gdb) bt #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 xftfreetype.c:994 #3 0x0804a74c in create_text_pixmap (drawing_area=0x80ea430, face=0x807d5a8) at font-view.c:67 #4 0x0804ba9b in main (argc=2, argv=0xbffff574) at font-view.c:452 (gdb) 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 works fine.
Keith referred me to http://freedesktop.org/pipermail/fontconfig/2004-March/000829.html.
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 present. 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 failure. 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 problems.
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.