http://bonsai.mozilla.org/cvsquery.cgi?date=explicit&mindate=2008-01-26+23:35&maxdate=2008-01-26+23:40 2008-01-26 23:37 karlt+%karlt.net mozilla/gfx/thebes/src/gfxPangoFonts.cpp 1.126 160/54 Bug 401988 – gfxPangoFontGroup::CreateGlyphRunsItemizing must use gfxPangoFont corresponding to the PangoFont from pango_shape (wrong glyphs selected when falling back to fonts of different style). Provide fontconfig with information re requested font even when non-existant. Map FONT_WEIGHT_NORMAL to Regular not Medium weight fonts. r=pavlov, sr=roc. made my ui fonts on linux fx and tbird go from the expected Bitstream Vera Sans to a serif font on ubuntu gutsy and debian testing, moz.org nightlies as well. The font is specified in Gnome's settings as "Sans" 10 on this machine, probably default.

or rather, looks like selecting Sans Regular 10, I get * moz apps: Bitstream Vera Serif Roman 10 (DejaVu Serif Book 10 seems to be spaced slightly differently) * others: DejaVu Sans Book 10 (Bitstream Vera Sans Roman 10 seems to be spaced slightly differently) (Don't ask me why they seem to mix up like that...) If I select one of those real fonts directly, it seems to be used correctly.

This issue shows up when the default Mozilla Western font (in Preferences->Content) is a non-generic (which is not the default, but many users may have changed this), but the GTK/Gnome font is a generic. The Mozilla font is appended to the font family matching pattern to give something like "Sans,Bitstream Vera Serif", which fontconfig resolves to "Bitstream Vera Serif". I think the default font in preferences is intended for document fonts so I don't think this preference should be added to the pattern for UI fonts. Removing FindGenericFontFromStyle() from the gfxPangoFontGroup constructor will resolve the issue. I just need to work out whether we still need to call this function for document fonts.

I think that you can use gfxFontStyle->systemFont for workaround.

(In reply to comment #3) > I think that you can use gfxFontStyle->systemFont for workaround. Thank you, that is an option that would resolve this issue, but I'm going to suggest removing FindGenericFontFromStyle(). nsRuleNode::SetFont() already ensures that there is a CSS generic in the family list. http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/style/nsRuleNode.cpp&rev=1.235&mark=2210-2215#2207 The default is either "serif" or "sans-serif" (CSS generics) according to the langGroup corresponding to the PresContext character set, or locale if the character set is Unicode. FindGenericFontFromStyle() is effectively appending another CSS generic but makes the sans or serif decision based on the DOM lang attribute. Perhaps FindGenericFontFromStyle() is making a better decision - I don't know. But having two generic fallback families does not gain us anything.

(I was considering doing this for 401988, but hadn't checked the style system thoroughly at that stage.)

(yes, attachment 300230 [details] [diff] [review] fixes the issue for me)

checked in: http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&branch=HEAD&cvsroot=%2Fcvsroot&date=explicit&mindate=1202798400&maxdate=1202798642&who=karlt%2B%25karlt.net