GNOME Bugzilla – Bug 332538
Pango (cairo/win32) lost the ability to render glyphs
Last modified: 2006-02-27 00:10:13 UTC
Just build from cvs and tried testgtk with newest Pango. Every glyph is replaced by the "unknown" box. Pango 1.10.x still works fine with the same build options and the same cairo version. A short look at the (win32 specific) changes from 1.10 to 1.11 does not reveal any obvious fault.
Created attachment 60109 [details] If you are curious how it looks like ...
Oops. Should be my fault somewhere. Can you try 0.11.{3,4,5} and see where that has been broken?
It got broken from 1.11.3 to 1.11.4; now I'm looking at the diffs again;)
Strange. I've just switched to pango 1.11.6 at work (gtk+ 2.8.12, glib 2.9.6, cairo 1.0.2) and haven't noticed any problems. Admittedly, I just installed the new version of the application and checked that it started up correctly (I develop under linux). I could find on Monday that there are problems, but the initial window seemed to come up correctly.
Even if it works for you it does not work for me. And there are probably a bunch of differences between our builds. From the top of my head (and some guessing): - you are using mingw, I'm using msvc - you are probably not using built-in modules. I am. - your build includes the UNISCRIBE dependency, mine does not. - you may use cairo/ft2. I dont. BTW: I have found the issue, it was a missing return TRUE in pango_cairo_win32_font_install(). Will commit shortly.
2006-02-25 Hans Breuer <hans@breuer.org> * pango/pangocairo-win32font.c(pango_cairo_win32_font_install) : return TRUE to glyphs rendered at all (instead of box). This may be compiler specific (what to return w/o return) but fixes bug #332538 * pango/makefile.msc : updated * pango/pango.def : just some sorting
Thanks! I had noticed the same problem, too, so it wasn't compiler specific.
The return value is typically whatever is left in eax or something, so it's very fragile...