Red Hat Bugzilla – Bug 616397
Pango regression in pangoft2 module
Last modified: 2013-11-14 05:32:33 EST
Description of problem:
I get this assertion failure every time I run texttopaps:
(texttopaps:10366): Pango-CRITICAL **: pango_font_description_set_size: assertion `size >= 0' failed
It comes from here:
fontmap = pango_ft2_font_map_new ();
fontset = pango_font_map_load_fontset (fontmap, pango_context, font_description, get_language ());
metrics = pango_fontset_get_metrics (fontset);
max_width = pango_font_metrics_get_approximate_char_width (metrics);
w = pango_font_metrics_get_approximate_digit_width (metrics);
if (w > max_width)
max_width = w;
page_layout.scale_x = 1 / page_layout.cpi * 72.0 * (gdouble)PANGO_SCALE / (gdouble)max_width;
g_object_unref (G_OBJECT (fontmap));
font_size = pango_font_description_get_size (font_description);
// update the font size to that width
==> pango_font_description_set_size (font_description, font_size * page_layout.scale_x);
...because both max_width and w are 0 for Courier, so page_layout.scale_x is inf.
Perhaps the calculation needs to be performed for a particular character? i.e. "what's the size of the character 'm'?"
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1./usr/lib/cups/filter/texttopaps 1 me '' 1 ''
Hmm, I may be missing something but I can't reproduce this here. though it looks strange to me that the approximate_char_width in the metrics is 0. anyway I need more information to reproduce this.
I managed to reproduce it using a pristine install of RHEL6.0-20100715.2-Workstation-x86_64 (i.e. Beta 6 Refresh 2).
This worked with pango-1.28.0 and it looks like no code to estimate the approximate character width on pangoft2. this would be a regression in pango.
upstrem fixed this issue:
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
*** Bug 747447 has been marked as a duplicate of this bug. ***
I have an interesting find and I'm hoping for feedback ...
/usr/lib/cups/filter/textopaps produces the error as above and doesn't work.
However, /usr/lib/cups/filters/texttopaps is just a symlink to /usr/bin/paps, and if I do:
echo "hello" | /usr/bin/paps > file.ps
.. the resulting file is perfectly fine!
This means that a patch should likely be easier than originally thought. ??
echo "hello" | /usr/bin/paps > file.ps
echo "hello" | /usr/bin/paps --font="Courier" or say --font="Times" does not work. It writes the file, but you don't get the document section including "hello".
I then found that I had added /usr/share/X11/fonts/100dpi to the font path via /etc/fonts/local.conf:
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
(It's not 100% clear why this wasn't added to the default font path, but I suppose because TrueType fonts are used instead these days.)
Removal of this line made paps work with --font="Courier" or --font="Times" without. However, paps never produced an error message, even when the resulting conversion to PS failed because I had the 100dpi fonts installed.
However, now, when I run textopaps, while I still get the pango error, the conversion seems to work perfectly now. Since paps doesn't generate that error in its normal operation, this leads me to believe that the error is generated by something added by the RH patch that adds cups support to paps.
You don't need to investigate anything else. the root cause has already been fixed in pango upstream as per the above comment says and no errors in paps at all.
Akira, pardon my ignorance please, but does this mean that I should be using texttopaps in the current fully updated RHEL6.1 version, or disabling it? Thank you.
You could use texttops from cups for fallback for text printing if you don't need i18n support. otherwise try to open the text on the editor and print it out there.
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development. This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.
*** Bug 672548 has been marked as a duplicate of this bug. ***