1841647 - Clipped character on dev.to article, with `text-rendering: optimizeSpeed`

Status: NEW

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

Description

[Daniel Holbert [:dholbert]]

Attachment: screenshot from Android

STR:

1. Load this site on an Android phone:
   https://dev.to/noamr/when-a-millisecond-is-not-a-millisecond-3h6
2. Look for this text at the end of a paragraph:

periodically adjusted to match UTC, using NTP.

ACTUAL RESULTS:
The "P" in NTP is visibly clipped on the right side.

EXPECTED RESULTS:
No clipping.

This seems to be due to the site having text-rendering:optimizeSpeed. If I add inline style text-rendering:initial to this element, then the P doesn't get clipped.

I can reproduce this on desktop, too, particularly after zooming in. E.g. at 200% full-page-zoom, it looks similar to the attached Android screenshot.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (slightly reduced)

Here's a standalone testcase from 'testcase reducer' that reproduces this for me.

Comment 2

[Daniel Holbert [:dholbert]]

(Note: I think some minor clipping/imprecise-rendering is to-be-expected with optimizeSpeed, but in this case it's pretty severe -- the P nearly looks like an F.

The question is whether that's a bug in Firefox or a bug in the font. And even if it's a font bug, perhaps compat demands that we be more graceful in the face of such font bugs? I can't repro the bug in Safari or Chrome so far. (Tested Safari on iOS and Chrome on the same android device where I initially noticed this in Firefox Nightly, which is a Pixel 6a.)

Comment 3

[Jonathan Kew [:jfkthame]]

The clipping arises (in optimizeSpeed mode) because the font's kerning of the <P, period> pair effectively reduces the advance width of the blue inline element (the link), and then the bowl of the P extends beyond the modified advance width. But in optimizeSpeed mode, we rely on the typographic bounds of the element (the advance width of the text, and the font's ascent/descent metrics) to determine the area we need to paint, rather than querying the individual bounds of every glyph that's present.

Bug 1836226 is another example of essentially the same thing: glyphs that extend beyond their nominal typographic extent (origin/advance) getting clipped in optimizeSpeed mode, because we don't inspect the individual glyph bounds.

So this is basically the compromise that the optimizeSpeed code makes: we assume that we just need to paint the nominal typographic bounding box, and don't compute per-glyph extents. But this can indeed sometimes result in glyphs getting clipped. I'm wondering if we should do something using the overall font bounding box to mitigate this, while still avoiding the need to get per-glyph bounds.