UI fails to pick up certain font variants from GNOME's configuration




8 years ago
7 years ago


(Reporter: Kasper Henriksen, Unassigned)



Firefox Tracking Flags

(Not tracked)




8 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20101026 Firefox/3.6.12
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: 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


8 years ago
Keywords: fonts


8 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

7 years ago
This is still happening with Firefox 8.
Ever confirmed: true
I guess pango_font_description_get_family() might be losing the variant info.

... 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

7 years ago

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()!
Thanks, Behdad.  Linking relevant docs.

A wonder whether there was any reason for setting the weight but not the slant.

Comment 6

7 years ago
No idea.
You need to log in before you can comment on or make changes to this bug.