The default bug view has changed. See this FAQ.

synthetic bold should be used where appropriate with system fallback fonts

RESOLVED FIXED in mozilla16



Graphics: Text
5 years ago
5 years ago


(Reporter: jfkthame, Assigned: jfkthame)


Mac OS X

Firefox Tracking Flags

(Not tracked)



(2 attachments, 1 obsolete attachment)



5 years ago
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 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, 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

5 years ago
Created attachment 634173 [details] [diff] [review]
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.
Attachment #634173 - Flags: review?(jdaggett)

Comment 2

5 years ago
Created attachment 634324 [details] [diff] [review]
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.
Attachment #634324 - Flags: review?(jdaggett)


5 years ago
Attachment #634173 - Flags: review?(jdaggett) → review+

Comment 3

5 years ago
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

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-

Comment 4

5 years ago
Created attachment 638284 [details] [diff] [review]
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.
Assignee: nobody → jfkthame
Attachment #638284 - Flags: review?(jdaggett)


5 years ago
Attachment #638284 - Flags: review?(jdaggett) → review+

Comment 5

5 years ago (patch) (tests)
Target Milestone: --- → mozilla16


5 years ago
Attachment #634324 - Attachment is obsolete: true
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.