GNOME Bugzilla – Bug 151068
GtkFontSelection asserts on Win32
Last modified: 2005-05-26 08:28:21 UTC
When selecting one of the fonts at the end of the list in the GtkFontSelection widget under Windows, I get the following assertion: **ERROR**: file shape.c: line 75 (pango_shape): assertion failed: glyphs->num_glyphs > 0) aborting... This appears to be related to the fonts with an at-sign ("@") at the beginning of their name, which I believe is Windows' way of designating a Unicode font -- If I have <n> Unicode fonts at the top of the list, selecting one of the last <n> items will throw an assertion.
No. *All* fonts used by Pango are Unicode fonts. The atsign name prefix indicates that the font is a synthetic one generated automatically by Windows. Windows does this for fonts containing CJK ideographs, the atsign fonts have their glyphs rotated 90 degrees for vertical writing. I don't think this causes the problem. (Anyway, I yesterday applied a patch for bug #145322 that makes Pango ignore these fonts.) Does the same problem occur if you select the non-atsign version of the font?
The at-signedness doesn't matter, AFAIK. If I have @font1 @font2 @font3 font4 font5 font6 ... font20 font21 font22 font23 then selecting fonts 21, 22, and 23 will cause the assertion. It's always the last <n> fonts, where <n> is the number of CJK fonts.
What fonts are these? Are they provided by Microsoft, or some 3rd party? If they are freely downloadable somewhere, could you give a pointer?
They are Arial Unicode MS, Batang, MS Mincho, PMingLiU, and SimSun. AFAIK, they came with XP.
It's vaguely possible that this is a duplicate of bug #149643, which I just fixed. Mail me if you want a fresh build of libpangowin32-1.0-0.dll that you can try to see if it helps.
After upgrading to a pangowin32 DLL with bug #149643 fixed, Gerald mails: > Got it. Thanks. After dropping the DLL into a default installation of > Ethereal 0.10.6, the synthetic fonts are no longer listed, and selecting > the last <n> fonts no longer generates the assertion. Unfortunately, I > now get the error when I select the "map symbols" font. All of the > other fonts appear to be fine. I found a copy of mapsym.ttf font using Google, and will try to fix the problems that GTK+ and/or Pango has with it.
*** Bug 160761 has been marked as a duplicate of this bug. ***
Not too happy with shipping 1.8 with this bug open - selecting the wrong font shouldn't lose your unsaved documented. So, I've put in what I think might be a quick fix for this bug, and if not, shouldn't do any harm. Wed Dec 15 23:13:57 2004 Owen Taylor <otaylor@redhat.com> * modules/basic/basic-win32.c (uniscribe_shape): Emergency fix for #151068... if uniscribe shaping comes up with no glyphs, fall back to non-uniscribe shaping. === @@ -931,7 +931,7 @@ uniscribe_shape (PangoFont *font, if (hfont != NULL) pango_win32_font_cache_unload (font_cache, hfont); - return retval; + return retval && glyphs->num_glyphs > 0; } === If glyphs->num_glyphs == 0 then we are in the assertion-will-fail case anyways, so we might as well try the fallback shaping. It would be very useful if someone analyzed what is going on in detail, however... why doesn't Uniscribe return an error at some point if it can't use the font? (If the above doesn't fix, then the Uniscribe path isn't involved at all, but it looks to me like we'll always get num_glyphs > 0 in the fallback case.) Moving to 'Need diagnosis' milestone for further investigation.
I finally for around to trying the mapsym.ttf file, and tried to select it in testgtk's font selection. (Without yet having Owen's 'emergency fix' in pangowin32.) At first I get: (testgtk.exe): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (o bject)' failed the immediate reason for which is that in pango-context.c: itemize_state_process_run(), around line 1120, if get_shaper_and_font() returns false, the code sets font to NULL but then proceeds to pass font to itemize_state_fill_shaper(), which does a g_object_ref() on the font. Pango is of course pretty confused at this point, and the next message is (testgtk.exe): Pango-CRITICAL **: _pango_engine_shape_shape: assertion `PANGO_IS _FONT (font)' failed and then finally the fatal error mentioned in the initial comment. I haven't right now time to check whether Owen's fix helps (I assume so), and whether it's the "correct" fix for the problems with the mapsym font (and others?) but will dig more into this later.
OK, sounds like my emergency fix doesn't fix anything ... since the previous warnings weren't reported, I was assuming that the problem was that the basic-win32 backend was returning empty glyph strings. The patch then probably should be reverted. It appears that the logic involving _pango_get_fallback_shaper() in pango-context.c isn't working correctly ... I *think* it would work to just put in if (font) checks in the places you mention above and also when unreffing the font. And we likely should do that. However, it's not really the optimum fix for the user, because they will get no display at all ... their text will just vanish: one of the following would be better: - Fallback to a font like "Sans" (question relating to this is what happens if you select a normal font like say "Arial" when the text string consists only of uncovered characters, like, say, Chinese ... does it trigger this bug as well?) - One unknown glyph character in the font the user selected for each character of the input string (looks like the fallback code in the basic-win32 shaper would give that if it was ever triggered) - Hex box display like the fontconfig backend What happens for the fontconfig backend is that first there is "any font on the system" font merging, and if that fails, you hit: if (!get_shaper_and_font (state, ' ', &shape_engine, &font)) in itemize_state_process_run(), and shaping with that font will produce the hex boxes. So the fallback shaper is only triggered if no font on the system has a space character in it.
BTW, what happens in the FreeType2 backend if one tries to use the mapsym.ttf file? (Google for it, it should be a file 7360 bytes in length (at least the one I am testing with is).) I iterated for a while running under the debugger, breaking on g_log, and each time I hit a warning or crash because of font being NULL inserting an appropriate check some levels up in the call stack, rebuilding libpango, repeat. It converged pretty quickly and now runs without warnings. But as you said, nothing at all is then displayed when using the map symbols font. But at least it doesn't crash. OK to commit the attached patch?
Created attachment 35102 [details] [review] Suggested patch
*** Bug 153178 has been marked as a duplicate of this bug. ***
*** Bug 162956 has been marked as a duplicate of this bug. ***
Created attachment 38971 [details] This is a hebrew font, a very common one, that is causing the same problem
*** Bug 170826 has been marked as a duplicate of this bug. ***
*** Bug 171851 has been marked as a duplicate of this bug. ***
*** Bug 172582 has been marked as a duplicate of this bug. ***
Hmm, actually currently in Pango (since , the win32 code ignores fonts in the SYMBOL_CHARSET (which means they don't have any Unicode mapping table). This means that fonts like Map Symbols and Guttman Yad can't be used at all ;-( But that's better than that they causes a crash. The fix is in Pango 1.8.0, and in the HEAD and pango-1-6 branches. I think this can be closed as a dupe of bug #149643. I can't reproduce this any longer anyway. For people who still use Pango 1.4.1, I guess the only solution is not to use fonts without Unicode mappings? *** This bug has been marked as a duplicate of 149643 ***
"People who still use Pango 1.4.1" includes everyone who uses Ethereal under Windows. This is a sizeable number -- O(100,000) downloads per month. Is there a newer version of Pango for Windows available? It doesn't appear to be listed on http://www.gimp.org/~tml/gimp/win32/downloads.html .
But why would one want to use non-Unicode fonts for Ethereal?
The patch from Comment #12 doesn't appear to have ever been committed (and the assertion at shape.c:75 still happens pretty frequently w/ Pango 1.8.0). Did it slip through the cracks or was it purposely abandoned?
No, I didn't commit that patch. It isn't really the correct solution. As the comment says, the result is just that nothing shows up at all. The correct solution would be to either prevent even trying to use fonts without a Unicode cmap at all, or to fake some mapping. Actually the first case should already be implemented in 1.8.0 (see ChangeLog.pre-1-8, entry from 2004-09-15). I think the problem here is that the same assertion in shape.c can be produced by different causes, which confuses the issue.