GNOME Bugzilla – Bug 330907
Critical warning when printing text with libgnomeprint
Last modified: 2006-11-07 22:28:52 UTC
Steps to reproduce: Printing with gedit a lot of critical warnings are produced: (gedit:30988): GnomePrint-CRITICAL **: gnome_rfont_get_glyph_stdadvance: assertion `glyph < GRF_NUM_GLYPHS (rfont)' failed (gedit:30988): GnomePrint-CRITICAL **: gnome_rfont_get_glyph_stdbbox: assertion `glyph < GRF_NUM_GLYPHS (rfont)' failed (gedit:30988): GnomePrint-CRITICAL **: gnome_rfont_render_glyph_rgb8: assertion `glyph < GRF_NUM_GLYPHS (rfont)' failed [snip] This is not due to gedit or gtksourceview since I get the same warnings using the "pango" test program in libgnomeprint/tests. Stack trace: Here a stacktrace I got using G_DEBUG=fatal_criticals and the "pango" test program:
+ Trace 66114
Let me know if you need more info. Other information:
Note that this unfortunately causes crashes for testers given the new policy of enabling fatal-criticals by default
This is clearly a blocker for gedit and all the apps using gnome-print to print text.
Copying from bug #332552. See that bug for the details of why this patch is needed. Hum.. In print preview, a bunch of g_return_if_fail (glyph < ...) are making sure the tab character is not rendered: (gedit:21872): GnomePrint-CRITICAL **: gnome_rfont_get_glyph_stdadvance: assertion `glyph < GRF_NUM_GLYPHS (rfont)' failed the glyph id that fails the assertion is the new value for an empty glyph... Don't know why it's not doing the same for the actually print to PDF. Lets see if it works: attachment #60192 [details].
Lowering pri on this since critical warning crashers shouldn't be blockers.
*** Bug 335859 has been marked as a duplicate of this bug. ***
behdad: I have just tested your patch, it does _not_ fix the warnings. I also does not fix bug #335759. Any idea?
Please also take a look at bug #334011, I guess that one is closely related to this bug (well, at least the critical warning is the same).
Created attachment 65465 [details] [review] patch used for the Ubuntu dapper package I've used that patch for the dapper package, that's the same as the previous one with the #ifdef moved after the #define so it actually does try if the value is defined by pango
Ah, right.
For me, the first patch doesn't fix bug #335859 (closed as a dup of this), but the recent patch fixes it. Thanks Sebastien!
Commiting this after checking with behdad.
*** Bug 348763 has been marked as a duplicate of this bug. ***
Some version of this bug appears to still be present (with ZWNJ, but not tab). Investigating.
OK. Another similar case exists in the libgnomeprint function gnome_rfont_get_glyph_stdadvance, triggered by the character U+200C ZERO-WIDTH NON-JOINER. The effect is the same (critical warnings on terminal when printing). The source is also the same: PANGO_GLYPH_EMPTY.
Roozbeh, so you see boxes too?
Roozbeh, I'm sure this bug is properly fixed. You probably are testing with an old libgnomeprint22. For example, in FC5 and FC6, it's 2.12.1 that is shipped. The patch was committed on 2006-08-15. I filed this bug about that: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214493
Well, there still remains the problem that you get those warnings and boxes when Pango tries to render a hexbox. libgnomeprint should use the pangoft2 fontmaps that don't support hexboxes, not whatever fontmap Gtk+ is using, but that will cause leaks currently, and since cairo+gtk+ is replacing the printing subsystem, I won't bother. FWIW, libgnomeprint's pango backend should be ported to PangoRenderer. Again, not worth the time.