1961387 - Poor rendering (bad metrics) of Noto Color Emoji font in vertical writing-modes

Status: RESOLVED FIXED

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

Description

[張俊芝(ZHANG Junzhi)]

Attachment: test.html

emojis get much bigger height than expected.

Comment 1

[張俊芝(ZHANG Junzhi)]

Attachment: test.html

The previous test file was corrupted. I've updated it with UTF-8 encoding.

Comment 2

[Jonathan Kew [:jfkthame]]

This is probably dependent on what emoji font is used. Which platform are you using? Please attach a screenshot of how it looks for you. Thanks!

Comment 3

[張俊芝(ZHANG Junzhi)]

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

This is probably dependent on what emoji font is used. Which platform are you using? Please attach a screenshot of how it looks for you. Thanks!

I am using deepin, which is a Linux Distro. And I've tries many local fonts by changing font-family, and the height remain wrong.
I've also confirmed that the these emojis work well in Chrome.

Comment 4

[張俊芝(ZHANG Junzhi)]

Attachment: Screenshot for Firefox.png

Comment 5

[張俊芝(ZHANG Junzhi)]

Attachment: Screenshot for Chrome.png

Comment 6

[張俊芝(ZHANG Junzhi)]

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

This is probably dependent on what emoji font is used. Which platform are you using? Please attach a screenshot of how it looks for you. Thanks!

FYI, after some research, I've found the actually used font is NotoColorEmoji.ttf (no matter whatever font-family I actually set because of the missing character fallback mechanism).
Can someone reproduce this issue using Noto Color Emoji?

Comment 7

[Jonathan Kew [:jfkthame]]

Attachment: left to right: apple color emoji, segoe ui emoji, noto color emoji

Interesting -- trying the example in Firefox on macOS, it looks ok with Apple Color Emoji, and also works ok with Segoe UI Emoji, but using Noto Color Emoji does render quite badly (though not quite the same as the reporter's screenshot from Linux).

So both the specific emoji font and the font backend (CoreText vs FreeType) we're using seem to be factors here.

Comment 8

[Jonathan Kew [:jfkthame]]

It looks like we end up with excessively large metrics for both glyph advance and line height when Noto Color Emoji is used in vertical mode.

The result in the reporter's screenshot is what happens when using the (older) bitmap version of Noto Color Emoji. Note that the result varies depending on the font size; it seems the metrics aren't being scaled appropriately. (Zoom the example to 400% and it looks roughly right!)

Replacing the Noto Color Emoji bitmap font with the newer COLRv1 version gives somewhat less awful results (similar to what's shown in my screenshot from macOS), but it's still not good.

Comment 9

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1961387 - Don't return a vertical-origin of zero for 'empty' truetype glyphs; fall back to computing the default vertical origin, so that if there's color-glyph data it will render in the right place. r=#gfx-reviewers

This fixes the bad positioning of Noto Color Emoji glyphs when using the
current (COLRv1) version of the font. GetGlyphVOrigin was incorrectly
returning zero because the 'glyf' data was empty; but the glyph will in
fact render, via the COLR codepath, and needs a valid origin to get
proper placement.

(The same issue could presumably affect an OpenType-SVG font that
similarly provides a 'vmtx' table but has empty 'glyf' records.)

I don't expect this to resolve the issue for the older bitmap (CBDT)
version of Noto Color Emoji; that will require a separate fix.

Comment 10

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1961387 - Simple reftest for Noto Color Emoji in vertical mode. r=#gfx-reviewers

Comment 11

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1961387 - Account for scaling of color-bitmap fonts when setting up the font-unit scale factor. r=#gfx-reviewers

This fixes the problem of color-bitmap Noto Color Emoji getting incorrect
glyph advances in vertical mode. Without the scaling correction here, we
end up with a constant glyph advance regardless of the font size, just
based on the "natural" size of the bitmap glyphs rather than the size
we're actually scaling them to.

Comment 12

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1961387 - Add a reftest with larger glyphs, for CBDT version of Noto Color Emoji. r=#gfx-reviewers

Without the scaling fix, the advance of the bitmap emoji glyph isn't
scaled according to the rendered size, and so the large glyph extends
beyond the expected rect.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a4ad6f718272
Don't return a vertical-origin of zero for 'empty' truetype glyphs; fall back to computing the default vertical origin, so that if there's color-glyph data it will render in the right place. r=gfx-reviewers,lsalzman
https://hg.mozilla.org/integration/autoland/rev/de68ee31172f
Simple reftest for Noto Color Emoji in vertical mode. r=gfx-reviewers,lsalzman
https://hg.mozilla.org/integration/autoland/rev/057a31f469ac
Account for scaling of color-bitmap fonts when setting up the font-unit scale factor. r=gfx-reviewers,lsalzman
https://hg.mozilla.org/integration/autoland/rev/ea30c0eca521
Add a reftest with larger glyphs, for CBDT version of Noto Color Emoji. r=gfx-reviewers,lsalzman

Comment 14

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/a4ad6f718272
https://hg.mozilla.org/mozilla-central/rev/de68ee31172f
https://hg.mozilla.org/mozilla-central/rev/057a31f469ac
https://hg.mozilla.org/mozilla-central/rev/ea30c0eca521

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/66e788b91a78
Revert "Bug 1961387 - Add a reftest with larger glyphs, for CBDT version of Noto Color Emoji. r=gfx-reviewers,lsalzman" for causing crashes (bug 1965123)

Comment 16

[Cristina Horotan [:chorotan]]

Backed out for causing crashes (bug 1965123)
https://hg.mozilla.org/integration/autoland/rev/82516541b4b1d46cc4d8694428a9e5448eeb6838

Comment 17

[Cosmin Sabou [:CosminS]]

Backout merged to central: https://hg.mozilla.org/mozilla-central/rev/66e788b91a785ecda515f8a25dc56acab6fc2d63

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1c1f408004e1
Don't return a vertical-origin of zero for 'empty' truetype glyphs; fall back to computing the default vertical origin, so that if there's color-glyph data it will render in the right place. r=gfx-reviewers,lsalzman
https://hg.mozilla.org/integration/autoland/rev/eafaeb768277
Simple reftest for Noto Color Emoji in vertical mode. r=gfx-reviewers,lsalzman
https://hg.mozilla.org/integration/autoland/rev/a884b6f401c3
Account for scaling of color-bitmap fonts when setting up the font-unit scale factor. r=gfx-reviewers,lsalzman
https://hg.mozilla.org/integration/autoland/rev/6e6b5ae23a5c
Add a reftest with larger glyphs, for CBDT version of Noto Color Emoji. r=gfx-reviewers,lsalzman

Comment 19

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/1c1f408004e1
https://hg.mozilla.org/mozilla-central/rev/eafaeb768277
https://hg.mozilla.org/mozilla-central/rev/a884b6f401c3
https://hg.mozilla.org/mozilla-central/rev/6e6b5ae23a5c

Comment 20

[Bogdan Maris, Desktop Test Engineering [OOO until 14th April]]]

Attachment: Emoji after the fix

I reproduced the initial issue using an old Nightly build from 2025-04-18 on Ubuntu 22.04, verified that the testcase from comment 1 looks much better using latest Nightly 141.0a1 and Firefox beta 140.0b5 across platforms (Ubuntu 22.04, macOS 13 and Windows 11). Though on Ubuntu (most evident) compared to Chrome the testcase still looks a bit off, see the attached image where I compare how the testcase looks in Chrome vs Firefox (Chrome / Nightly / Beta).
Jonathan, do you think this is alright or there can be done something more to improve the result here?

Comment 21

[Jonathan Kew [:jfkthame]]

I think we can just call this fixed. The difference vs Chrome shown in comment 20 is largely a case of using different default fonts for the ASCII digits, so the renderings aren't really comparable.