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)

x86
Linux
defect

Tracking

()

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
Keywords: fonts
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
This is still happening with Firefox 8.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
... 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.
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()!
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.
No idea.
Severity: minor → S4
Component: Graphics → Graphics: Text
You need to log in before you can comment on or make changes to this bug.