Open
Bug 610293
Opened 14 years ago
Updated 1 year ago
UI fails to pick up certain font variants from GNOME's configuration
Categories
(Core :: Graphics: Text, defect)
Tracking
()
NEW
People
(Reporter: infenwe, Unassigned)
Details
(Keywords: fonts)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Ubuntu/10.04 (lucid) Firefox/3.6.12 When using the Condensed variants of the DejaVu fonts for applications in GNOME, XUL chooses the regular variants instead. Reproducible: Always Steps to Reproduce: 1. Make sure GNOME is using DejaVu Sans Condensed (or Serif Condensed) as "Application font" in Appearance Properties. 2. (Re)start any of Firefox, Thunderbird or Seamonkey. Actual Results: Comparing menu and tab fonts in your favourite avian application to that of any GNOME application, you'll notice that they use different fonts for their UI. Expected Results: The avian applications are clearly able to pick up the correct font family, so they should be able to get the correct variant too. This is similar to and probably related to bug 419001, but does not involve a UI font chooser. Instead it appears that the backend that's responsible for figuring out the font for the UI fails to read the configuration correctly. This bug has a known work-around: edit userChrome.css to include the following line: * { font-family: dejavu sans condensed !important; } Curiously there's also a small bug (or possibly I don't understand userChrome.css as well as I should): Using that in your userChrome.css, tooltips still render using regular DejaVu. I find that last part particularly puzzling yet rather unimportant
Updated•14 years ago
|
Component: XUL Widgets → Graphics
Product: Toolkit → Core
QA Contact: xul.widgets → thebes
Summary: XUL fails to pick up certain UI fonts from GNOME's configuration → UI fails to pick up certain font variants from GNOME's configuration
Comment 1•13 years ago
|
||
This is still happening with Firefox 8.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•13 years ago
|
||
I guess pango_font_description_get_family() might be losing the variant info. http://hg.mozilla.org/mozilla-central/annotate/854aabf544d4/gfx/src/nsSystemFontsGTK2.cpp#l208
Comment 3•13 years ago
|
||
... which would be correct behaviour for pango_font_description_get_family, but, if we don't want that behaviour, then we need to do something else.
Comment 4•12 years ago
|
||
Karl, Five lines below what you linked there are these lines: 213 // FIXME: Set aFontStyle->stretch correctly! 214 aFontStyle->stretch = NS_FONT_STRETCH_NORMAL; Just set the stretch from pango_font_description_get_stretch()!
Comment 5•12 years ago
|
||
Thanks, Behdad. Linking relevant docs. http://developer.gnome.org/pango/1.28/pango-Fonts.html#pango-font-description-get-stretch http://developer.gnome.org/pango/1.28/pango-Fonts.html#PangoStretch A wonder whether there was any reason for setting the weight but not the slant.
Comment 6•12 years ago
|
||
No idea.
Updated•2 years ago
|
Severity: minor → S4
Updated•1 year ago
|
Component: Graphics → Graphics: Text
You need to log in
before you can comment on or make changes to this bug.
Description
•