First up, you should go and watch The Importance of Being Earnest with Ncuti Gatwa. It is a brilliant set of performances and a joy to see.
While perusing the programme on the National Theatre website I stumbled upon a little bug. The incredible Ronkẹ Adékọluẹ́jọ́ has her name rendered in a most unusual style:
It rendered just fine in Chrome - but both Firefox and Safari misrendered some of the accented characters.
Here's a minimum viable demo to show what's happening:
Fonts are hard, OK?!?!
Broadly speaking0, accented characters can be made in two way.
- Pre-composed. There is a separate code for the character
é - Combining. The plain letter
eis immediately followed by the combining character◌́and the computer smushes them together.
Similarly, a font file can have separate little drawings for each accented character or it can have separate accents.
In this case, the National Theatre is using the font "Helvetica Now Display W04".
The web font contains é (U+00E9) and both ◌́ (U+0301) & ̣◌ (U+0323).
But doesn't include ẹ (U+1EB9) or ọ (U+1ECD).
So the ẹ́ and ọ́ have to be made by combining characters in the font.
On Chrome this works. On Firefox and Safari, it seems to break when the CSS is set to font-weight: normal;. This causes the browser to render those characters in the default fallback font - hence the slightly weird look.
Next Steps
I've raised a bug with Firefox and one with WebKit.
Of course, it might be that they're doing the right thing and Chrome is in the wrong - but I think that's unlikely.
Now, time to fix the font I use on this website to prevent any rendering errors!
-
It is a lot more complicated than that. ↩︎
3 thoughts on “An odd font rendering bug in Firefox and Safari”
@blog @Edent The same, or actually a different, problem for Safari (webkit) on her wikipedia page https://en.wikipedia.org/wiki/Ronk%E1%BA%B9_Ad%C3%A9k%E1%BB%8Dlu%E1%BA%B9%CC%81j%E1%BB%8D%CC%81?wprov=sfti1
Firfox seems to work here.
| Reply to original comment on mastodon.social
So interesting! Looks like we’ve been looking into this here: bugs.webkit.org/show_bug.cgi...
| Reply to original comment on bsky.app
@blog 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.
| Reply to original comment on chaos.social
More comments on Mastodon.