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 149643 - pango-basic-win32 doesn't always load metrics? (Symbol font)
pango-basic-win32 doesn't always load metrics? (Symbol font)
Status: RESOLVED FIXED
Product: pango
Classification: Platform
Component: win32
1.4.x
Other Windows
: Normal normal
: ---
Assigned To: gtk-win32 maintainers
pango-maint
: 148169 150653 151068 152473 300399 309311 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-08-08 14:37 UTC by David Turner
Modified: 2005-07-05 10:51 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description David Turner 2004-08-08 14:37:23 UTC
* pango-1.4.0 from http://www.gimp.org/~tml/gimp/win32/downloads.html
* With PyGTK:

import gtk
import pango
fd = pango.FontDescription("symbol 12")
w = gtk.Window()
f = w.get_pango_context().load_font(fd)
f.get_metrics()

Results in:

(:2868): GLib-GObject-CRITICAL **: file gobject.c: line 1561 (g_object_ref):
assertion `G_IS_OBJECT (object)' failed

** (:2868): CRITICAL **: file pango-engine.c: line 68
(_pango_engine_shape_shape): assertion `PANGO_IS_FONT (font)' failed

Or when you set the font for a widget to Symbol, you get this message box:

** Error: ** file shape.c: line 75 (pango_shape): assertion failed:
(glyphs->num_glyphs > 0)
aborting...

This only seems to happen with fonts that contain symbols, such as Symbol and
Wingdings.
Comment 1 Daniel Atallah 2004-08-19 23:17:39 UTC
This also happens under Pango 1.4.1 and using a plain C gtk application.  If
necessary, i can throw together a sample application that easily replicates the
issue, but it can easily be replicated in Gimp or Gaim by simply trying to use
the Symbol font.

I guess that the worst part about this issue is that it causes the whole
application to exit - it seems that this problem could be handled more elegantly.
Comment 2 Tor Lillqvist 2004-09-15 19:30:25 UTC
*** Bug 152473 has been marked as a duplicate of this bug. ***
Comment 3 Tor Lillqvist 2004-09-15 21:51:45 UTC
Fixed in HEAD and pango-1-4:

2004-09-15  Tor Lillqvist  <tml@iki.fi>

* pango/pangowin32-fontmap.c (pango_win32_insert_font): Ignore
fonts in SYMBOL_CHARSET. They don't have any Unicode mapping
table. (#152473)
Comment 4 David Turner 2004-09-16 09:34:20 UTC
So we don't get to use these at all?  I have a music notation TTF which I'd like
to use.  It works fine with Freetype on Linux, but won't work on Win32 because
of the lack of a Unicode mapping.  Tor, I can look into producing a patch for
this if you like.
Comment 5 Tor Lillqvist 2004-09-16 09:43:59 UTC
The fix was to the pangowin32 backend. No FreeType involved at all there.

How does that music notation font work on Linux? How does Pango work with a 
font that has no Unicode mapping? Just assign some random mapping from Unicode 
characters to glyphs in the font? What software do you use that font with, is 
Pango involved at all? Or even GTK+?
Comment 6 Owen Taylor 2004-09-16 12:16:34 UTC
Actually, Pango (well, more, fontconfig) cna handle fonts with the 
Adobe symbol encoding.

But it can't use a font with no recognized encoding table, unless you
use the PangoFcDecoder functionality in Pango-1.6.
Comment 7 David Turner 2004-09-16 14:38:55 UTC
In this particular case, I copied the TTF file from my Windows box to my Debian
box, and ran the same PyGTK program on both.  It worked on the Debian box, but
not on the Windows box.  The difference, as far as I can tell, is that the
Freetype backend somehow produces a mapping (most likely just ordinal 1:1),
while the Win32 backend barfs.  It looks like I'll have to dig into the libft2
code to figure out what exactly is going on.  Just reporting what I've observed.
 I'll do a more scientific check and identify the versions involved when I get
home tonight.
Comment 8 Hans Breuer 2004-09-19 21:25:17 UTC
*** Bug 150653 has been marked as a duplicate of this bug. ***
Comment 9 Hans Breuer 2004-09-19 21:36:32 UTC
*** Bug 148169 has been marked as a duplicate of this bug. ***
Comment 10 Tor Lillqvist 2005-04-04 14:18:07 UTC
*** Bug 151068 has been marked as a duplicate of this bug. ***
Comment 11 weskaggs 2005-04-13 15:43:49 UTC
*** Bug 300399 has been marked as a duplicate of this bug. ***
Comment 12 Tor Lillqvist 2005-07-05 10:51:15 UTC
*** Bug 309311 has been marked as a duplicate of this bug. ***