[css-fonts-4] Localized font name matching, and WPT

[svgeesus]

I notice that some WPT, such as font-family-name-015.xht have assertions like

The 'font-family' property set to and installed font renders the appropriate font. Localized fullname should not match.

This assertion (in what was originally a CSS 2.1 test) contradicts CSS Fonts 4, 5.1. Localized name matching which states:

Some font file formats allow font faces to carry multiple localizations of a particular string (e.g. family name or named instance). User agents must recognize and correctly match all of these names independent of the underlying platform localization, system API used, or document encoding.

Presumably this explains some of why no current browser passes a bunch of these tests

Presumably those tests should be corrected, flipping the pass criteria?

@drott @jfkthame

[drott]

CC @MaxIhlenfeld

[jfkthame]

Hmm, we need to be careful here to pay attention to exactly which names we're talking about.

CSS Fonts 4 says that localized family names must be matched, but it also says (in 4.3.3.1. Local font fallback) that localized full font names must not be matched; only the en-US full name (or first localization, if en-US is not present) is to be matched by src: local(...). And when used directly in font-family, matching any full name would be an error: full name ≠ family name. (See also 2.1.4. Relationship Between Faces and Families.)

In the case of font-family-name-015.xht, the name it uses "ＣＳＳテスト　フォント名 Bold" looks like it's a localized full (not family) name, and as such the test is correct to assert that it should not match (either for font-family, as in the test, or if it were to be used in a @font-face rule's src:local(...)).

I think the primary reason for the failures currently seen on wpt.fyi is that the CSS test fonts aren't installed on the machines running the tests. (ISTR seeing some recent activity that looked like someone is in the process of making them available, so this situation may improve shortly.)

Once the test fonts are actually installed, we can review the validity of whatever test failures remain.

[svgeesus]

(ISTR seeing some recent activity that looked like someone is in the process of making them available, so this situation may improve shortly.)

I saw that too, and (apparently incorrectly) thought that had now been done, so expected the WPT failures to have turned into passes today. I guess I should calibrate my enthusiasm.

[jfkthame]

(ISTR seeing some recent activity that looked like someone is in the process of making them available, so this situation may improve shortly.)

Hmm, I think what I noticed in passing was https://chromium-review.googlesource.com/c/chromium/src/+/6512831, but AFAICT that's about adding the CSS Test fonts in chromium's CI, but it hasn't done anything to install them on the WPT test runners. There was an associated WPT PR, but that just updated a variation-font test to remove use of src:local(...); it wasn't about the WPT test environment.

(Aside: I think it's a bit unfortunate that the WPT PR generated in a case like this ends up with the same summary as the original Blink [or Gecko, or whatever] change, but this may not be at all reflective of what's actually being touched in WPT. The result is that a lot of PRs have quite confusing/misleading summaries in the WPT context.)