1267909 - "Noto Color Emoji" font takes up a minimum of 64px of height, even at small sizes

Status: VERIFIED FIXED

(Core :: Graphics: Text, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

A while ago I symlinked the Noto Color Emoji font from https://github.com/mozilla-b2g/moztt into my ~/.fonts/ directory and created a .config/fontconfig/conf.d/65-emoji.conf (which I'll attach) to make this font be used.  This didn't work at the time because fontconfig wouldn't match the font, I believe because it was a bitmap font.

Upgrading from Ubuntu 15.10 (wily) to Ubuntu 16.04 LTS (xenial) made this start working.

However, it has the strange result that characters rendered in the Noto Color Emoji font add a *ridiculous* amount of extra line-height, presumably because we're getting strange metrics for the font somehow.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: 65-emoji.conf

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: simple testcase

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: screenshot of testcase

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: screenshot of part of this bug report

This shows why this bug is rather annoying to me. :-)

Comments are affected similarly, although it's not quite as bad there.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It seems like this is related to the font being a bitmap font containing multiple sizes.  If I break in gfxFont::SanitizeMetrics, the entire metrics struct looks like metrics appropriate for a much larger font (emHeight = 55, maxHeight = 64) when mStyle.size is 12 (and mStyle.sizeAdjust is -1).

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Actually, maybe it's just that it's a bitmap font, since the available multiple sizes are heights of 64 and 128.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: gdb/rr session

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Also note that if I increase the font size (using devtools), the "extra" space reduces (i.e., the size required stays the same), and the problem goes away around a size of 50px or 55px.

Comment 9

[Behdad Esfahbod]

What's happening is that the font has 64px bitmaps.  The fact that they need to be scaled is reflected in FC_MATRIX element of the font pattern.  Cairo handles that correctly.  I don't know where Firefox is getting its metrics from, that misses this in layout.

Comment 10

[Dan D (volunteer tester from the community)]

I can confirm experiencing this issue. (Linux Mint 18.1)

This makes it so Firefox users can't properly use the latest Noto Color Emoji font from https://github.com/googlei18n/noto-emoji/ unless they can deal with the rather tall line-spacing.

The font works normally in chromium.

Comment 11

[Lee Salzman [:lsalzman]]

Attachment: fix line heights to properly scale to requested size for color-bitmapped SFNTs

In the FreeType metrics, ascender/descender/max_advance/height all depend on y_ppem. Now that we treated SFNTs with color bitmaps as scalable as Fontconfig decrees, going by the y_ppem is wrong in this case. We must scale those 4 metrics based on the requested size.

Incidentally, Cairo already does this internally for its own metrics, since we are passing this requested size to Cairo, so we were disagreeing with in this particular case too.

This patch fixes that up, so the line heights are now actually correct, rather than based on the original y_ppem (which for Noto Color Emoji is the huge 109 value, hence the observed bug).

Comment 12

[Azurit3]

Attachment: Test http://emojipedia.org/unicode-9.0/

In Firefox 53 I notice a change in the render of characters with the Noto Color Emoji font. Now the characters will not scale down, and will take all the extra line-height observed in the previous Firefox versions.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/75cf7bb24193
fix line heights to properly scale to requested size for color-bitmapped SFNTs. r=jfkthame

Comment 14

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/75cf7bb24193

Comment 15

[Lee Salzman [:lsalzman]]

David, can you verify if this is fixed in the latest central?

Comment 16

[Lee Salzman [:lsalzman]]

Comment on attachment 8866011 [details] [diff] [review]
fix line heights to properly scale to requested size for color-bitmapped SFNTs

Approval Request Comment
[Feature/Bug causing the regression]: Old pre-existing condition. So affects all channels.
[User impact if declined]: Third-party emoji fonts will not be spaced correctly on Linux.
[Is this code covered by automated tests?]: no
[Has the fix been verified in Nightly?]: yes
[Needs manual test from QE? If yes, steps to reproduce]: no
[List of other uplifts needed for the feature/fix]: This is necessary to combine with the uplifts already in bug 1360682 to resolve recent issues with both scaling and spacing of third-party emoji fonts.
[Is the change risky?]: low risk
[Why is the change risky/not risky?]: Only affects third-party emoji fonts (not the builtin emoji), and only on Linux.
[String changes made/needed]: none

Comment 17

[Gerry Chang [:gchang]]

Hi Brindusa, is this issue you can help verify in the latest Nightly build? Thanks!

Comment 18

[Brindusa Tot, Desktop QA]

I tried to verify this on Ubuntu 16.04 x64 and I could not reproduce the initial issue on latest Nightly build 55.0a1, from 05-15-2017 and on Nightly build 55.0a1 from 05-06-2017.
Tried with the attached test case in comment 2 and with the link from comment 12: http://emojipedia.org/unicode-9.0/. In my case, on both Nightly builds the emoji looks exactly the same.

David, could you please check on your side to see if this is fixed on the latest Nightly?

Comment 19

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I temporarily uncommented the contents of my 65-emoji.conf, and confirmed that:
 * the bug was still present in the 2017-05-09 Linux nightly
 * the bug is no longer present in the 2017-05-11 Linux nightly
and therefore I've verified that this bug was fixed in the range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b21b974d60d3075ae24f6fb1bae75d0f122f28fc&tochange=d8762cb967423618ff0a488f14745f60964e5c49

Comment 20

[Gerry Chang [:gchang]]

Comment on attachment 8866011 [details] [diff] [review]
fix line heights to properly scale to requested size for color-bitmapped SFNTs

Fix a "Noto Color Emoji" font issue and was verified. Beta54+. Should be in 54 beta 9.

Comment 21

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-beta/rev/7067d6a7dc74d854498ff5f45a45b74431e21160

Comment 22

[Paul Silaghi, QA [:pauly]]

based on comment 19

Comment 23

[Julien Cristau [:jcristau]]

Comment on attachment 8866011 [details] [diff] [review]
fix line heights to properly scale to requested size for color-bitmapped SFNTs

as in bug 1360862, esr52-

Comment 24

[Bogdan Maris, Desktop QA]

Reproduced the initial issue using an old Nightly from 2017-02-15 and instructions from comment 0. I verified that the issue is no longer reproducible using latest Firefox 54 beta 9 on Ubuntu 16.04 64bit.

Comment 26

[Guo Yunhe]

I can reproduce this in Firefox 55 on openSUSE Tumbleweed, though it seems fixed in previous version.

Comment 27

[Guo Yunhe]

Attachment: Screenshot of Firefox 55 and Konqueror Emoji Test

In Firefox 55, Noto ColorEmoji is blank, though the size is normal. I am not sure if it is the same bug or a new one.