765906 - synthetic bold should be used where appropriate with system fallback fonts

Status: RESOLVED FIXED

(Core :: Graphics: Text, defect)

Description

[Jonathan Kew [:jfkthame]]

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.

Comment 1

[Jonathan Kew [:jfkthame]]

Attachment: patch v1 - don't ignore boldness when using system fallback fonts

Note that this also fixes the existing reftest failure on Android for defaultjapanese-bold.html.

Comment 2

[Jonathan Kew [:jfkthame]]

Attachment: reftests for synthetic bold with system-fallback fonts

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.

Comment 3

[John Daggett (:jtd)]

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.

Comment 4

[Jonathan Kew [:jfkthame]]

Attachment: reftests for synthetic bold with system-fallback fonts, v2

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.

Comment 5

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f749cea93c54 (patch)
https://hg.mozilla.org/integration/mozilla-inbound/rev/e1557cf22891 (tests)

Comment 6

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/f749cea93c54
https://hg.mozilla.org/mozilla-central/rev/e1557cf22891