1962602 - ch unit seems to break font face unicode range

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[[e-mail]]

Attachment: unicoderange-ch-unit.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:137.0) Gecko/20100101 Firefox/137.0

Steps to reproduce:

On a page, we have two CSS font-face declarations: one with no range, and another one with a range containing all the characters present in a page.
If we load the page, all is working well, only the last font, containing the range, is downloaded. But if we add somewhere in a css file a ch unit, all fonts are downloaded.
According to the spec, the ch unit relies on the 0 character to compute size. Even if the character is included in the range, all fonts are downloaded.

You can check an example here: https://codepen.io/jr_/pen/pvveOEa

Actual results:

All the fonts are downloaded

Expected results:

Only the font containing the characters in the page should be loaded

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Text and Fonts' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Jonathan Kew [:jfkthame]]

Yeah, this seems unfortunate. It's not just the ch unit, either (which in theory depends on measuring the "0" character); other font-relative units like ex or cap (which are only dependent on font metrics, not on a specific character) also have the effect.

One issue here -- I'm not sure if it's the only issue -- is that when any of the CSS font-based units are used, we go ahead and retrieve the metrics for all of them (see gfxFontGroup::GetMetricsForCSSUnits). The trouble is, that may result in loading multiple font resources, because to set up all the font units, we need (a) the metrics from the "first available font", for things like ex and cap; (b) the face that provides the character "0", to measure the ch unit; and (c) the face that provides the "水" (U+6C34, water ideograph) character, for the ic unit.

In the example here, two faces are provided in the "myfont" family; one has a unicode-range that declares a limited selection of characters (Latin-1, or thereabouts), but the other has no unicode-range (i.e. it uses the "initial value" of U+0-10FFFF). Therefore, when we're trying to resolve the ic unit, we fetch that resource -- even though in fact it doesn't support U+6C34.

If the first resource (the latin-ext subset) had a unicode-range descriptor specifying its actual character coverage, I believe this wouldn't happen.

Comment 3

[Jonathan Kew [:jfkthame]]

Incidentally, if you modify the CSS to use the ic unit instead of ch, you'll see Chrome also downloading both resources, as it attempts to resolve ic and doesn't know that the latin-ext subset resource (with no unicode-range) won't support it.

So it looks like Chrome takes a more granular approach to the font-related units, only retrieving the metrics for the specific unit(s) used, while we're setting them all up as a group if any of them are used.

Comment 4

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1962602 - Give gfxFontGroup::GetMetricsForCSSUnits flags to control whether it should load extra font resources to measure the ZERO or WATER IDEOGRAPH characters. r=#style

This makes the style system pass flags down to GetMetricsForCSSUnits to specify
whether it needs the 'ch' or 'ic' units, which may trigger downloading additional
font resources.

There should be no change in user-visible behavior, except by observing (e.g. in
the devtools network panel) what resources end up being fetched in an example
like the reporter's.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/06dedc60ea29
Give gfxFontGroup::GetMetricsForCSSUnits flags to control whether it should load extra font resources to measure the ZERO or WATER IDEOGRAPH characters. r=firefox-style-system-reviewers,emilio

Comment 6

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/06dedc60ea29