Bug 308 - some pcf fonts fail to be rendered with >=Xft-2.1.3
Summary: some pcf fonts fail to be rendered with >=Xft-2.1.3
Status: CLOSED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Lib/Xft (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: high major
Assignee: Keith Packard
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 213
  Show dependency treegraph
 
Reported: 2004-03-15 14:48 UTC by foser
Modified: 2011-10-15 17:14 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description foser 2004-03-15 14:48:13 UTC
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.
Comment 1 Donnie Berkholz 2004-03-16 13:38:41 UTC
Keith referred me to
http://freedesktop.org/pipermail/fontconfig/2004-March/000829.html.
Comment 2 foser 2004-03-16 15:59:42 UTC
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 ?
Comment 3 Keith Packard 2004-03-16 16:58:23 UTC
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.
Comment 4 Bugzilla Maintainer 2004-03-19 12:27:29 UTC
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.
Comment 5 foser 2004-03-22 05:49:53 UTC
This solution works for me afaics.
Comment 6 Keith Packard 2004-03-22 06:34:04 UTC
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.