Bug 141876
Summary: | Print/print preview does not display Lucida Typewriter | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Emmanuel Kowalski <emmanuel.kowalski> | ||||||||
Component: | pango | Assignee: | Behdad Esfahbod <behdad> | ||||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | |||||||||
Severity: | medium | Docs Contact: | |||||||||
Priority: | medium | ||||||||||
Version: | 5 | CC: | dpoon | ||||||||
Target Milestone: | --- | ||||||||||
Target Release: | --- | ||||||||||
Hardware: | i386 | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | 2.12.3 | Doc Type: | Bug Fix | ||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2008-03-10 06:02:45 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: | |||||||||||
Attachments: |
|
Description
Emmanuel Kowalski
2004-12-04 15:50:01 UTC
Created attachment 107894 [details]
A screenshot of a print preview of a test message
This is a print preview of a message with Lucida Typewriter selected as
terminal font.
Created attachment 107895 [details]
Same message as previous attachment with monospace
This is the same message with Monospace font; the message displays in
print preview as it should.
Created attachment 107896 [details]
A screenshot of print preview from gedit with Lucida font
This shows that the print preview from gedit can display text in Lucida
Typewriter font.
Thanks. I can reproduce this bug on my own machine. The "box" seems to take up the room that the text would have occupied e.g. on a long email it can take multiple pages. I've just spent a lot of time troubleshooting this bug too. Here's what I found: LucidaTypewriter is a bitmap font. (It's supplied by the bitmap-fonts RPM -- to verify this: mv /usr/share/fonts/bitmap-fonts /usr/tmp ; fc-cache /usr/share/fonts ; restart evolution and see that LucidaTypewriter disappears from the font choices.) If you try another of the bitmap fonts, such as Console?x?, Evolution will also fail to print it. A similar problem got filed upstream here: http://bugzilla.gnome.org/show_bug.cgi?id=302904 What happend if you try printing/print preview with bitmap fonts from other GNOME apps? e.g. gedit Sorry, I just re-read comment #3 - it looks to be Evolution-specific. gedit avoids the problem by not presenting a font choice to the user at all for printing! The font selector in gedit's preferences dialog affects only the screen, not the printing. In the gedit source code, in gedit-prefs-manager.c, function gedit_prefs_manager_get_print_font_body(void), you'll see where it decides what font to use. It does a gconf lookup on /apps/gedit-2/preferences/print/fonts/print_font_body_pango and /apps/gedit-2/preferences/print/fonts/print_font_body, defaulting to "Monospace 9". If you fire up gconf-editor and set /apps/gedit-2/.../print_font_body to "LucidaTypewriter Sans 11" and .../print_font_body_pango to "LucidaTypewriter 11", you'll see the print preview come out blank in exactly the same way that Evolution fails. So, this suggests that Evolution should either semi-hard-code the print font, or add another font choice ("Print Font") in addition to Standard Font and Terminal Font. FYI, the code path in Evolution for setting the font is as follows: Evolution mail prefs UI sends a gconf signal mail-config.c: config_write_style() writes a .gtkrc file gtkhtml picks it up in gtkhtml.c: gtk_html_set_fonts(...) gtkhtml takes care of the printing Thanks for the comments. I'm going to reassign this to libgnomeprint22 since it appears to be a generalized problem with printing (In reply to comment #8) > So, this suggests that Evolution should either semi-hard-code the print > font, or add another font choice ("Print Font") in addition to Standard Font > and Terminal Font. On second thought, neither of my suggestions is ideal. We still haven't found the root cause for the blank printout. Assuming that it really is impossible to print using a bitmap font, the next best thing would be to automatically substitute a similar font. But that seems more like upstream development work. Fedora Core 3 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thank you! The bug is still present in the current FC5 version: [root@semillon log]# rpm -q evolution evolution-2.6.2-1.fc5.5 Thanks. Looks like a pango bitmap font issue as this is present even when using the new gtkprint stuff. J5, did you test with cairo 1.2? It's more of a cairo issue, to be exact... Fedora Core 5 is no longer maintained. Is this bug still present in Fedora 8? The bug is not there with Fedora 8, but the print preview is quite ugly and blocky (much worse than with gedit). But of course there are many better choices of (non bitmap) font, so this is now a very minor issue. |