Bug 616397
| Summary: | Pango regression in pangoft2 module | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Tim Waugh <twaugh> |
| Component: | pango | Assignee: | Akira TAGOH <tagoh> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Desktop QE <desktop-qa-list> |
| Severity: | urgent | Docs Contact: | |
| Priority: | urgent | ||
| Version: | 6.0 | CC: | eng-i18n-bugs, jas, jhunt, jmontleo, jwest, msanders, rnelson, tagoh, tpelka |
| Target Milestone: | rc | Keywords: | Patch, Regression, ZStream |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | pango-1.28.1-7.el6 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-11-14 10:32:33 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 662543, 782183, 878772 | ||
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: http://git.gnome.org/browse/pango/patch/?id=955b51cc5221a2624ea6c49c3f42e6f32f127419 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 representative. 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 representative. *** 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. ?? Ah interesting.. echo "hello" | /usr/bin/paps > file.ps ... works. 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: <?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> <dir>/usr/share/X11/fonts/100dpi</dir> </fontconfig> (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. *** |
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; pango_font_metrics_unref (metrics); 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): paps-0.6.8-13.el6.x86_64 How reproducible: 100% Steps to Reproduce: 1./usr/lib/cups/filter/texttopaps 1 me '' 1 ''