User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:18.0) Gecko/18.0 Firefox/18.0 Build ID: 20120919030602 Steps to reproduce: Open up a page with Helvetica Neue and Turkish letters, i.e. https://twitter.com/_glass/status/248710927720005632 Actual results: The letters are rendered incorrectly, they appear to be bold. Expected results: They should appear regularly.
Component: Untriaged → Layout: Text
Product: Firefox → Core
The link provided shows Georgia instead of Helvetica. A better page would be: https://twitter.com/SALOMgazetesi
That page looks fine here. Could you (a) try with a fresh profile, to see if any custom settings or addons you're using may be affecting it; and (b) post a screenshot of exactly what you're seeing. Thanks.
Tried a fresh profile and nothing changed. I'll attach a screenshot.
OK, I can see what you mean in that screenshot - but I don't see the same problem locally. Please go to about:support, click "Copy all to clipboard", and paste the resulting text here, so we can see more details of your configuration. Also, please install the font-info addon (https://addons.mozilla.org/en-us/firefox/addon/fontinfo/), then select one of the "problem" words and choose Show Fonts in Selection from the context menu (ctrl-click), to verify exactly what font(s) are actually being used.
On 10.6 (used by Roman), only the 'medium weight' of Helvetica Neue contains those characters. On 10.8 at least (and 10.7 ?), all weights contain them. 'Medium' is slightly bolder than normal. Safari appears to fallback to helvetica on my 10.6 system (which does contain those characters).
Created attachment 663208 [details] test case On 10.6, the 3 offending characters are displayed using a serif font with both Gecko and WebKit browsers.
The fonts used are "Helvetica Neue", "Helvetica Neue Medium". And yes, the fallback was what confused me. So Chrome and Safari have a different fallback algorithm.
Hmm. Yes, Firefox will try to find the character in a different face of the same family, before falling back to searching other font families. I think in most cases that's appropriate. It happens in this particular example that Safari's fallback from Helvetica Neue to Helvetica gives you a good-looking result, because the designs are so similar, but cross-family fallback will rarely find such a closely-matching font. Related to this, the "font matching algorithm" in the (evolving) CSS3 Fonts specification has gone through a number of changes. I notice that the latest Working Draft at http://www.w3.org/TR/2012/WD-css3-fonts-20120823/#font-matching-algorithm has something that would behave like Firefox, in that it calls for choosing a face from among "the set of font faces in that family that contain a glyph for the character"; however, the Editor's Draft at http://dev.w3.org/csswg/css3-fonts/#font-matching-algorithm has reverted to an algorithm that would behave like Safari, as it calls for choosing a face from among the faces in the family (without regard to character inventory); and then if the face chosen doesn't support the character in question, abandon that family and fall back to the next. Firefox used to have that behavior, but we deliberately changed it in bug 668813 because the old behavior gave undesired results in some cases (and at that time, the CSS3 Fonts draft called for the new behavior). John, any thoughts? I don't think I'd noticed you reverting the algorithm in the current ED... was that in response to a specific decision in the WG? If so, does that mean we need to revert 668813 (which I think would be an unpopular move)?
You need to log in before you can comment on or make changes to this bug.