After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 151068 - GtkFontSelection asserts on Win32
GtkFontSelection asserts on Win32
Status: RESOLVED DUPLICATE of bug 149643
Product: pango
Classification: Platform
Component: win32
1.4.x
Other Windows
: Normal normal
: Need diagnosis
Assigned To: gtk-win32 maintainers
gtk-bugs
: 153178 160761 162956 170826 171851 172582 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-08-25 22:03 UTC by Gerald Combs
Modified: 2005-05-26 08:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Suggested patch (3.26 KB, patch)
2004-12-21 23:17 UTC, Tor Lillqvist
none Details | Review
This is a hebrew font, a very common one, that is causing the same problem (39.04 KB, application/octet-stream)
2005-03-20 19:52 UTC, Itai Bar-Haim
  Details

Description Gerald Combs 2004-08-25 22:03:28 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.
Comment 1 Tor Lillqvist 2004-08-25 23:55:25 UTC
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?
Comment 2 Gerald Combs 2004-08-26 02:42:14 UTC
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.
Comment 3 Tor Lillqvist 2004-08-26 20:41:30 UTC
What fonts are these? Are they provided by Microsoft, or some 3rd party? If 
they are freely downloadable somewhere, could you give a pointer?
Comment 4 Gerald Combs 2004-08-26 22:59:48 UTC
They are Arial Unicode MS, Batang, MS Mincho, PMingLiU, and SimSun.  AFAIK, they
came with XP.
Comment 5 Tor Lillqvist 2004-09-15 21:55:37 UTC
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.
Comment 6 Tor Lillqvist 2004-09-19 09:07:24 UTC
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.
Comment 7 Owen Taylor 2004-12-16 04:14:37 UTC
*** Bug 160761 has been marked as a duplicate of this bug. ***
Comment 8 Owen Taylor 2004-12-16 04:25:42 UTC
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.
Comment 9 Tor Lillqvist 2004-12-17 06:01:50 UTC
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.
Comment 10 Owen Taylor 2004-12-17 14:48:17 UTC
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.
Comment 11 Tor Lillqvist 2004-12-21 23:16:56 UTC
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?
Comment 12 Tor Lillqvist 2004-12-21 23:17:57 UTC
Created attachment 35102 [details] [review]
Suggested patch
Comment 13 Hans Breuer 2004-12-22 23:18:57 UTC
*** Bug 153178 has been marked as a duplicate of this bug. ***
Comment 14 Morten Welinder 2005-01-04 21:51:28 UTC
*** Bug 162956 has been marked as a duplicate of this bug. ***
Comment 15 Itai Bar-Haim 2005-03-20 19:52:21 UTC
Created attachment 38971 [details]
This is a hebrew font, a very common one, that is causing the same problem
Comment 16 weskaggs 2005-03-20 21:51:23 UTC
*** Bug 170826 has been marked as a duplicate of this bug. ***
Comment 17 weskaggs 2005-03-28 14:46:04 UTC
*** Bug 171851 has been marked as a duplicate of this bug. ***
Comment 18 Tor Lillqvist 2005-04-04 07:56:19 UTC
*** Bug 172582 has been marked as a duplicate of this bug. ***
Comment 19 Tor Lillqvist 2005-04-04 14:18:03 UTC
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 ***
Comment 20 Gerald Combs 2005-04-04 16:12:39 UTC
"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 .
Comment 21 Tor Lillqvist 2005-04-04 23:53:48 UTC
But why would one want to use non-Unicode fonts for Ethereal?
Comment 22 Daniel Atallah 2005-05-26 02:40:42 UTC
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?
Comment 23 Tor Lillqvist 2005-05-26 08:28:20 UTC
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.