| Summary: | some pcf fonts fail to be rendered with >=Xft-2.1.3 | ||
|---|---|---|---|
| Product: | xorg | Reporter: | foser <foser> |
| Component: | Lib/Xft | Assignee: | Keith Packard <keithp> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | high | CC: | dberkholz |
| Version: | unspecified | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Bug Depends on: | |||
| Bug Blocks: | 213 | ||
|
Description
foser
2004-03-15 14:48:13 UTC
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.