For a given element with a given style, if a downloadable font is used, the rendering of that element will vary depending upon which styles are used on the page. This is due to changes in the font matching logic made for bug 668813, where not only the font selected for a given style (e.g. the bold italic font) but *all* fonts in the family that support a character are checked. Testcase: These tests use a font family that defines on 'A' for the regular face and both 'A' and 'B' for the italic face. Due to this, the string "ABC" will render differently depending upon whether the italic face was loaded for use on other parts of the page. With italics: http://people.mozilla.org/~jdaggett/tests/cmapvariationtest-italic.html Without italics: http://people.mozilla.org/~jdaggett/tests/cmapvariationtest-noitalic.html I'm partly to blame here, I put in wording in the CSS3 font matching algorithm that requires this sort of matching but the more I think about it the more I don't think it's a good fit for the on-demand nature of downloadable fonts, nor is it the right approach in all situations. Families with cmap variations across faces aren't typical but several of the core web fonts do have variations which is why it's important to consider this.

Do you think this is serious enough that we should avoid shipping the changes in bug 668813 without this fixes as well? If so, please nominate for tracking.

(In reply to David Baron [:dbaron] from comment #1) > Do you think this is serious enough that we should avoid shipping the > changes in bug 668813 without this fixes as well? Not IMO; the issue here is a relatively obscure edge-case that's unlikely to occur with "normal" web-font usage where a family with multiple styles has the same character coverage in all faces. OTOH, the issue in bug 668813 affected real-world sites using common platform fonts like Arial and Times New Roman.

Is this bug still a pertinent issue or can we close this? John, can you still reproduce this issue?