GNOME Bugzilla – Bug 318168
Pango font selection is on crack
Last modified: 2005-11-17 12:31:12 UTC
Distribution/Version: Gentoo This is a bug I'm constantly experiencing since I moved to Pango 1.10: sometimes, when I start a programme, Pango renders the wrong font instade of the one it was supposed to render. Most of the time I notice it when using Evolution -- I use the Bitstream Vera fonts for UI (through the generic Sans family), and regular text does show up correctly, but bold text is rendered in Arial. For example, when I get a new e-mail it shows up in bold Arial, and when I open it it turns to regular Bitstream Vera Sans. This behaviour, however, is not always reproducible, but I do enounter it at least once a day.
Both me and Carl Worth have experienced that too. I noticed it after upgrading from FC3 to FC4, so I think it doesn't have anything to do with Pango 1.10 exactly. Looks more like a fontconfig problem though. Just checked, happens for me both with 1.8.3 and newer pangos. fontconfig-2.2.3-13. I think I tried the other day and it happened with fontconfig-2.4 branch of CVS too. What I'm observing is, I run ./pango-xftview ./HELLO.utf8, the Arabic text should be rendered using Nazli, that's what my font configuration does, and it does. But sometimes, randomly, it picks up Tahoma. I had bitmap fonts installed, and it used to pick up the bitmap font instead of Tahoma. I think we are experiencing the same bug, whatever and whereever it is.
I'm attaching 5 shots of pango-xftview ./HELLO.utf8. It's not just Arabic, a bunch of scritps change font across shots. Note how Burmese and a couple other ones lose their hex-boxes in some of the shots, which is happening probably because some font has empty glyphs for them? The way it looks like to me is a font chosen for some run slipping into other ones. Why it's not deterministic, I have no idea. Last time I checked this, I valgrind'ed it and no problems found. :(
Created attachment 53198 [details] shot1 shot 1, with: Arabic: Nazli Bengali: empty glyphs Burmese: Hex boxes Greek: A decent font Hindi: empty glyphs
Created attachment 53199 [details] shot2 shot 1, with: Arabic: Nazli Bengali: empty glyphs Burmese: Hex boxes Greek: bitmap font Hindi: empty glyphs
Created attachment 53200 [details] shot3 shot 1, with: Arabic: Nazli Bengali: empty glyphs Burmese: empty glyphs <---- Greek: A mismatch of fonts <---- Hindi: empty glyphs
Created attachment 53202 [details] shot4 shot 4, with: Arabic: Nazli Bengali: empty glyphs Burmese: Hex boxes Greek: A decent font Hebrew AND the comma after "Hindi": Another font <---- Hindi: empty glyphs
Created attachment 53203 [details] shot5 shot 5, with: Arabic: Tahoma <---- Bengali: empty glyphs Burmese: Hex boxes Greek: A decent font Hebrew: A third font! <---- Hindi: Hex boxes! <----
What a spam I made! So looks like the whole font selection is under crack, somehow not for Latin though.
With Mattias Clasen's help, I figured out that turning address space randomization (echo 0 > /proc/sys/kernel/randomize_va_space) makes the behavior deterministic. A bug with comparing pointers somewhere.
Nailed it down. Very tricky: language was used in hash function, but not in hash equal function. So it was only showing up if two language pointers had the same hash value. So the VM randomization. Fixed in HEAD and pango-1-10. 2005-11-17 Behdad Esfahbod <behdad@gnome.org> * pango/pangofc-fontmap.c (fontset_hash_key_equal): Compare language too. (#318168)
Humm, now thinking that this may not solve the problem in the original report that didn't have anything to do with language. Reopen if you still experience the problem.