Closed Bug 765906 Opened 8 years ago Closed 8 years ago
synthetic bold should be used where appropriate with system fallback fonts
Currently, we don't apply synthetic bold to fonts that are found during system fallback. I think this is wrong: it means that elements with "bold" styling are not rendered as expected when fallback is in effect. For example, on OS X with default fonts installed, view http://chr.wikipedia.org/wiki/%E1%8F%A9%E1%8E%A6%E1%8F%A7%E1%8E%A7%E1%8F%85%E1%8F%8D%E1%8F%95%E1%8E%BE_%E1%8E%A4%E1%8F%82%E1%8E%BE%E1%8F%97%E1%8F%85%E1%8F%97. There are several <b> elements within the first couple of paragraphs, but because OS X ships with only a regular face of the Plantagenet Cherokee font, the <b> elements are not visually differentiated from the surrounding text. Similarly, http://dz.wikipedia.org/wiki/%E0%BD%A6%E0%BE%90%E0%BD%B4%E0%BC%8B%E0%BD%A0%E0%BD%81%E0%BD%BC%E0%BD%A2%E0%BC%8B%E0%BD%82%E0%BE%B1%E0%BD%B2%E0%BC%8B%E0%BD%A2%E0%BE%92%E0%BE%B1%E0%BD%B4%E0%BD%91%E0%BC%8B%E0%BD%94%E0%BC%8D has a number of <b> elements, but because the Tibetan fonts on OS X only have a regular face, the visual distinction is lost. This will become a more widespread issue on Android, where it is likely that more scripts will have only a single weight available as devices do not typically ship with anywhere near as rich a collection of fonts as a desktop OS.
Note that this also fixes the existing reftest failure on Android for defaultjapanese-bold.html.
Attachment #634173 - Flags: review?(jdaggett)
A couple of testcases that check we're applying synthetic bold when necessary with a fallback font. These examples are designed to test the issue on OS X, where the scripts being used have only a single-weight family.
Attachment #634324 - Flags: review?(jdaggett)
Comment on attachment 634324 [details] [diff] [review] reftests for synthetic bold with system-fallback fonts Why do the reftests fail on WinXP/Android? If it's because of a lack of fonts that support those scripts, I don't think you should be using fail-if here but instead random-if(!target). That way you won't cause reftest failures on machines that happen to lack fonts for those scripts. Since this patch affects all platforms, I think you should be including tests for Windows/Android, not just ones targeted at OSX.
Attachment #634324 - Flags: review?(jdaggett) → review-
OK, after entirely too many tryserver runs, here's a revised version of the tests. These cover OS X (all current versions) and Win7 (unaccelerated, using GDI) using a Cherokee script example, as both systems ship the same regular-face-only Cherokee font, and Android using chess symbols. I don't see an obvious way to test WinXP, due to lack of suitable fonts that we can reliably expect to reach via the system fallback path. The tests are skipped on Linux because (a) the whole system-fallback codepath is completely different (and largely out of our direct control) in the fontconfig world anyway, so it's not clear what we should test, and (b) my tryserver runs kept hitting bug 769659 on Linux64. That looks like a separate issue we should try to investigate, but shouldn't block this fix.
Assignee: nobody → jfkthame
Attachment #638284 - Flags: review?(jdaggett)
https://hg.mozilla.org/integration/mozilla-inbound/rev/f749cea93c54 (patch) https://hg.mozilla.org/integration/mozilla-inbound/rev/e1557cf22891 (tests)
Target Milestone: --- → mozilla16
Attachment #634324 - Attachment is obsolete: true
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.