Prior to this change, if none of the fonts specified in CSS contained a
glyph for a codepoint, we tried only one fallback font. If that font
didn't contain the glyph, we'd give up.
With this change, we try multiple fonts in turn. The font names we try
differ across each platform, and based on the codepoint we're trying to
match. The current implementation is heavily inspired by the analogous
code in Gecko, but I've used to ucd lib to make it more readable,
whereas Gecko matches raw unicode ranges.
This fixes some of the issues reported in #17267, although colour emoji
support is not implemented.
== Notes on changes to WPT metadata ==
=== css/css-text/i18n/css3-text-line-break-opclns-* ===
A bunch of these have started failing on macos when they previously
passed.
These tests check that the browser automatically inserts line breaks
near certain characters that are classified as "opening and closing
punctuation". The idea is that if we have e.g. an opening parenthesis,
it does not make sense for it to appear at the end of a line box; it
should "stick" to the next character and go into the next line box.
Before this change, a lot of these codepoints rendered as a missing
glyph on Mac and Linux. In some cases, that meant that the test was
passing.
After this change, a bunch of these codepoints are now rendering glyphs
on Mac (but not Linux). In some cases, the test should continue to pass
where it previously did when rendering with the missing glyph.
However, it seems this has also exposed a layout bug. The "ref" div in
these tests contains a <br> element, and it seems that this, combined
with these punctuation characters, makes the spacing between glyphs ever
so slightly different to the "test" div. (Speculation: might be
something to do with shaping?)
Therefore I've had to mark a bunch of these tests failing on mac.
=== css/css-text/i18n/css3-text-line-break-baspglwj-* ===
Some of these previously passed on Mac due to a missing glyph. Now that
we're rendering the correct glyph, they are failing.
=== css/css-text/word-break/word-break-normal-bo-000.html ===
The characters now render correctly on Mac, and the test is passing. But
we do not find a suitable fallback font on Linux, so it is still failing
on that platform.
=== css/css-text/word-break/word-break-break-all-007.html ===
This was previously passing on Mac, but only because missing character
glyphs were rendered. Now that a fallback font is able to be found, it
(correctly) fails.
=== mozilla/tests/css/font_fallback_* ===
These are new tests added in this commit. 01 and 02 are marked failing
on Linux because the builders don't have the appropriate fonts installed
(that will be a follow-up).
Fix build errors from rebase
FontTemplateDescriptor can no longer just derive(Hash). We need to
implement it on each component part, because the components now
generally wrap floats, which do not impl Hash because of NaN. However in
this case we know that we won't have a NaN, so it is safe to manually
impl Hash.
This is a step towards fixing #17267. To fix that, we need to be able to
try various different fallback fonts in turn, which would become
unweildy with the prior eager-loading strategy.
Prior to this change, FontGroup loaded up all Font instances, including
the fallback font, before any of them were checked for the presence of
the glyphs we're trying to render.
So for the following CSS:
font-family: Helvetica, Arial;
The FontGroup would contain a Font instance for Helvetica, and a Font
instance for Arial, and a Font instance for the fallback font.
It may be that Helvetica contains glyphs for every character in the
document, and therefore Arial and the fallback font are not needed at
all.
This change makes the strategy lazy, so that we'll only create a Font
for Arial if we cannot find a glyph within Helvetica. I've also
substantially refactored the existing code in the process and added
some documentation along the way.
Issue #17321. Under Linux, using "font-family: sans-serif" previously
caused Servo to select the "UltraLight" face (of DejaVu Sans). There
were two reasons for this:
1. Font weight was only retrieved from the OS/2 table for bold faces.
This neglected to retrieve the weight information for "lighter than
normal" weight faces. This meant that the UltraLight face appeared as
normal weight, and was selected.
2. Retrieval of font stretch information from the OS/2 table was not
implemented at all.
Previously anything with the wrong stretch/italicness was considered
equally bad. Now we consider the wrong weight to be least bad, wrong
boldness of intermediate badness, and wrong itallicness to be most
bad.
`FontContext::get_layout_font_group_for_style()`.
There are several optimizations here:
* We make font families atoms, to allow for quicker comparisons.
* We precalculate an FNV hash of the relevant fields of the font style
structure.
* When obtaining a platform font group, we first check pointer equality
for the font style. If there's no match, we go to the FNV hash. Only
if both caches miss do we construct and cache a font group. Note that
individual fonts are *also* cached; thus there are two layers of
caching here.
15% improvement in total layout thread time for Facebook Timeline.
