Bug 308087 – REGRESSION (305325@main): Layout of columns is incorrect for some fonts

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Brad Andalman]

Created attachment 478392 [details]
HTML using Fanwood that has a third column that's too low

In our multi-column layouts, we expect that the baselines of each line match across the columns. In Safari Technology Preview 237 (and therefore in Tahoe 26.4 b1), this is no longer true. For some fonts, certain columns suddenly start much lower than they should.

This bug seems dependent upon the font, font size, and text. However, I was able to reproduce this easily using Fanwood Text and Noto Sans, both used via Google Fonts. 

I will attach HTML and screenshots that illustrate this bug. (Note that in these attachments, the issue arises in the third column. I've set it up like this to avoid https://bugs.webkit.org/show_bug.cgi?id=284677, which affects the baselines across columns one and two.

[Brad Andalman]

Created attachment 478393 [details]
HTML using Noto Sans that has a too-low third column

[Brad Andalman]

Created attachment 478394 [details]
Screenshots of both Safari and STP 237 illustrating the bug using Fanwood

[Brad Andalman]

Created attachment 478395 [details]
Screenshots of both Safari and STP 237 illustrating the bug using Noto Sans

[Radar WebKit Bug Importer]

<rdar://problem/170594582>

[Ahmad Saleem]

It is broken on ToT (Minibrowser - 307727@main) as well.

https://jsfiddle.net/92Lj0tas/ (without -webkit- prefixes), it works on both Firefox Nightly 149 and Chrome Canary 147 and don't have issue on third column.

[Brad Andalman]

I believe this changed in this commit: https://commits.webkit.org/305325@main

(I downloaded the WebKit Build Archives for 305324@main and 305325@main, and the bug only appears in the latter.)

[alan]

Yeah, that's correct. I managed to trace it back to that commit too.

[Tim Nguyen (:ntim)]

Pull request: https://github.com/WebKit/WebKit/pull/59040

[alan]

Created attachment 478429 [details]
Test reduction

[alan]

Looks like ink overflow coming specifically from glyph overflow pushes content down. Ink overflow should have zero impact on line geometry.

[EWS]

Committed 307942@main (280cd6f5cdbb): <https://commits.webkit.org/307942@main>

Reviewed commits have been landed. Closing PR #59040 and removing active labels.

[alan]

(In reply to alan from comment #10)
> Looks like ink overflow coming specifically from glyph overflow pushes
> content down. Ink overflow should have zero impact on line geometry.

I misspoke. This is some pagination specific hack:
 
    // FIXME: For now we paginate using line overflow. This ensures that lines don't overlap at all when we
    // put a strut between them for pagination purposes. However, this really isn't the desired rendering, since
    // the line on the top of the next page will appear too far down relative to the same kind of line at the top
    // of the first column.

^^ comment from 2013.

and that's exactly what's happening here: 305325@main introduced improved glyph overflow handling, and this font reports relatively large glyph overflow, and turning it to ink overflow causes the lines to be pushed downward.

[alan]

while ^^ is all correct, we slightly over-inflate glyph overflow and it causes paginated lines to shift. bug 308389 fixes the over-inflation and makes the attached test case pass.

[EWS]

Committed 305413.361@safari-7624-branch (3feee966809f): <https://commits.webkit.org/305413.361@safari-7624-branch>

Reviewed commits have been landed. Closing PR #4551 and removing active labels.