2023126 - Broken rendering of a font with combining diacritics (content vs font normalization form mismatch)

Status: UNCONFIRMED

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

Description

[Terence Eden]

Attachment: Rendering bug.

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:148.0) Gecko/20100101 Firefox/148.0

Steps to reproduce:

Under some circumstances, diacritic combinators are not applied when using web fonts.

For example, on the page https://www.nationaltheatre.org.uk/artists/ronke-adekoluejo/ the name "Ronkẹ Adékọluẹ́jọ́" renders incorrectly.

Minimum viable demo at https://codepen.io/edent/pen/qEaRyrz

Actual results:

Firefox doesn't render the combined characters properly, but Chrome does.

The web font contains é (U+00E9) and both ́ (U+0301) & ̣ (U+0323).
But doesn't include ẹ (U+1EB9) or ọ (U+1ECD).
This means the following characters don't render well: ẹ ẹ́ ọ

I think this is caused by the font-weight: normal; CSS property.

Expected results:

Firefox on desktop and mobile should render the text correctly.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Firefox for Android::Browser Engine' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Terence Eden]

(In reply to BugBot [:suhaib / :marco/ :calixte] from comment #1)

The Bugbug bot thinks this bug should belong to the 'Firefox for Android::Browser Engine' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

It affects the desktop rendering engine as well.

Comment 3

[Jonathan Kew [:jfkthame]]

Safari shows the same issue, too.

This is not "caused by the font-weight: normal; CSS property", though that does exacerbate the issue and make it much more obvious. But if you look carefully at the last two lines in the codepen (where font-weight: normal is omitted, and therefore the weight is 700 (i.e. bold) from the h1 tag), there's still a mismatch between the characters that are supported by the "NT" webfont and those that fall back to the default sans-serif. On macOS, at least, this is quite visible with the "e" glyph; results will vary on different platforms depending on the default sans-serif.

What's happening is that (as described in comment 0) the "NT" webfont does not support the precomposed Unicode codepoints for ẹ ẹ́ ọ, and so font fallback occurs for those characters. If the content used the same (partially-)decomposed representation as the font resource supports, there would be no problem. Compare https://codepen.io/jfkthame/pen/zxKZGyW, where I've added a second version of the text, encoded with ̣ for the dot-below to match the font.

The reason that font-weight: normal seems to make it worse is that it overrides the bold weight from the h1 tag, and so the fallback font renders with a lighter weight. But the "NT" webfont remains bold because no normal-weight resource has been provided for that family -- or to be pedantic, the provided resource is considered to be normal weight (despite having rather bold glyphs), as there's no font-weight descriptor in the @font-face rule. This makes the difference between the webfont glyphs and the fallback ones more glaring. Without font-weight: normal, the fallback glyphs at least use the bold face of the default sans-serif, so the mismatch is less obvious.

Anyhow, in short, the solution would be to ensure that the webfont resource being used supports all the characters required as encoded in the content (typically in Unicode NFC form).

Comment 4

[Terence Eden]

Apparently, this is how Chrome does it:

We're doing what we call shaper-driven segmentation in Chrome where we let HarfBuzz identify the best match between codepoint sequence in the page vs. coverage in the font, including unicode composition/decomposition, anchor positioning, glyph synthesis etc. - to my knowledge Safari and Firefox scan fonts for coverage first before they proceed to segmentation. The advantage is that Chrome tends to keep combined characters rendered together in the same font.

https://chaos.social/@drott/116224314867557686

Comment 5

[Jonathan Kew [:jfkthame]]

Yes, I know how Chrome does it. Currently neither Firefox nor Safari behave that way, so creating content that depends on Chrome's particular implementation of font selection and fallback makes for a fragile experience, as seen in this example.

Comment 6

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

The severity field is not set for this bug.
:jfkthame, could you have a look please?

For more information, please visit BugBot documentation.

Comment 7

[Jonathan Kew [:jfkthame]]

As described above (comment 3), the underlying issue here is a poorly-authored site where the provided font resource doesn't fully support the content; but marking as a potential enhancement, as doing something similar to Chrome's "shaper-driven" font selection could sometimes improve the results with such content.