1818837 - Firefox on HiDPI Wayland renders text in a way that looks misaligned, with some fonts (e.g. BreveText Book), due to rendering the text at up-scaled sizes

Status: NEW

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

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (using Wired-hosted BreveText-Book.woff)

[I think this isn't exactly our bug, but I keep running into it and it manifests as a Firefox-specific issue in my environment, so I figured I'd get it on file in case there's any mitigation we might want to do down the line...]

STR:

1. Use Ubuntu 22.04 with Wayland (selectable at user-login time), with 125% display scaling (in the Ubuntu settings app, "Displays" section)
2. Launch Firefox and visit a Wired article like this one:
   https://www.wired.com/story/beware-a-new-google-drive-scam-landing-in-inboxes/
   ...and look at the words "the" and "is" in the first paragraph.

(Or just load my attached reduced testcase, which use 19px "Breve Text Book" text.)

ACTUAL RESULTS:
The letters with curvy bottoms (t, e) extend 1px lower than the letters with flat bottoms (h, i). This makes the words look misaligned.

EXPECTED RESULTS:
Properly-aligned-looking text.

I can't reproduce in Chrome with default settings. But I think that's due to rendering resolution differences, with my special 125% zoom level.
Firefox reports a window.devicePixelRatio of 2, whereas Chrome reports 1.

So I think we are in fact rendering the text as if it had font-size: 38px (2x the specified size of 19px) and then we're getting downscaled to match the actual OS 125% pixel scale factor, or something along those lines.

If I explicitly specify font-size: 38px in Chrome, then I can reproduce the "protruding curvy descender" issue there. But it also looks less-weird at these high levels, since it's still only protruding 1px down from a much larger character.

SO: essentially, Firefox (on Wayland at least) is getting some sort of ceil() applied to the OS zoom factor, and then our rendering output gets scaled down to the actual fractional zoom factor at some level; and this ends up meaning that we use glyphs with large-character decorations at smaller sizes than where those glyphs are intended to be used.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase on Firefox vs. Chrome, and `window.devicePixelRatio` values, and display 125% scaling

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (using Wired-hosted BreveText-Book.woff at size 19px)

oops, sorry -- I had edited the font-size before posting the attachment, making the bug not quite as obvious / not as faithful to the original Wired article. --> Reposting to fix that.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase on Firefox vs. Chrome, and `window.devicePixelRatio` values, and display 125% scaling

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: 8x-zoomed-in screenshot of testcase 1 in Firefox (showing "s" visibly descending 1px lower)

Comment 5

[Thomas Wisniewski [:twisniewski]]

FWIW, this is also happening for me on X11 at certain zoom scales as well.

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (using Wired-hosted BreveText-Book.woff at size 38px)

Here's a testcase where I've doubled the font-size to 38px (which I think (?) is what we're doing under the hood when selecting our glyphs, or something along those lines, based on the window.devicePixelRatio that we're using).

With this version, Chrome renders the "s" a little bit lower than the "i" just like we do for testcase 1. So they're agreeing with us on how the glyphs-of-this-size should be laid out. The difference is just that we're using this layout at substantially-more-scaled-down text sizes, due to the fact that we're arriving at a ceil()-rounded-up devicePixelRatio for some reason.

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: 8x-zoomed-in screenshot of testcase 2 in Chrome (showing "s" visibly descending 1px lower, for sufficiently large font-size)

Here's a

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: screenshot of how this looks on Wired at Firefox (left) vs. Chrome (right)

For comparison, here's a screenshot of how this actually looks when I view the article in Firefox vs. Chrome. A bunch of words end up looking "bumpy" on the bottom in Firefox vs. "flat/aligned" in Chrome, due to this behavior difference. E.g. "and", "that", "is", etc. (any word with a mix of curvy-bottom & flat-bottom characters)

Comment 9

[Daniel Holbert [:dholbert]]

(The word "very", near the bottom center of my screenshotted article-text, 4-5 lines from the bottom -- that contains a very -- has an additional interesting issue in Firefox -- the "e" protrudes on the bottom and the top, noticeably sticking up and down by 1px vs. its "v" neighbor. As discussed above for "is", I think this is meant to be a subtle 1px decorative bump at high font sizes (e.g. 38px), but we end up showing it as a less-subtle 1px bump at relatively low font sizes (19px in this case).

Comment 10

[Jonathan Kew [:jfkthame]]

Yeah, the font is designed with some "overshoot" of curved lines beyond the nominal baseline or ex-height that you would expect them to be aligned with. This is actually a well-established design practice. You can see this happening in a font like Times New Roman, for example, if you try:

data:text/html,<span style="font:800px times;text-decoration-skip-ink:none;text-decoration:1ex yellow underline;text-underline-offset:-1ex">aeiou

Note how the curved glyphs project slightly above/below the yellow backdrop, compared to the flat bottom of "i" and top of "u".

So as a design feature in the font, this is common; but the result we're getting with this BreveText font is unfortunate. I'm a bit surprised that we report a devicePixelRatio of 2 there; I thought we'd changed things to handle fractional dPR at some point, which would likely produce a better result here. But if we force dPR to be an integer and then scale the rasterized glyphs to the final size, I guess we expected that scaling down would be better than scaling up. Which it probably is in many cases, but here it looks a bit rough.

Comment 11

[Daniel Holbert [:dholbert]]

(In reply to Jonathan Kew [:jfkthame] from comment #10)

I'm a bit surprised that we report a devicePixelRatio of 2 there; I thought we'd changed things to handle fractional dPR at some point, which would likely produce a better result here.

Following up on this note -- I believe we do support fractional dPR in general, but on Wayland in particular, there are platform-level issues, with a fix making its way to users. See https://www.phoronix.com/news/Wayland-Fractional-Scale-Ready regarding a patch that was merged in Nov 2022 (which I suspect won't make it to Ubuntu 22.04 users like myself).

So in the meantime, I assume that the OS has a pile of hacks that are partly/poorly faking support for fractional scaling, by e.g. pretending we've got a whole-number scale factor and then doing a supplemental scale on top of that.