Closed Bug 1267909 Opened 4 years ago Closed 3 years ago

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


(Core :: Graphics: Text, defect)

Not set



Tracking Status
firefox-esr45 --- wontfix
firefox-esr52 --- wontfix
firefox53 --- wontfix
firefox54 --- verified
firefox55 --- verified


(Reporter: dbaron, Assigned: lsalzman)



(Whiteboard: [gfx-noted])


(8 files)

A while ago I symlinked the Noto Color Emoji font from 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.
This shows why this bug is rather annoying to me. :-)

Comments are affected similarly, although it's not quite as bad there.
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).
Actually, maybe it's just that it's a bitmap font, since the available multiple sizes are heights of 64 and 128.
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.
Summary: "Noto Color Emoji" font has bizarre metrics → "Noto Color Emoji" font takes up a minimum of 64px of height, even at small sizes
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.
Whiteboard: [gfx-noted]
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 unless they can deal with the rather tall line-spacing.

The font works normally in chromium.
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).
Assignee: nobody → lsalzman
Attachment #8866011 - Flags: review?(jfkthame)
Has STR: --- → yes
OS: Unspecified → Linux
Hardware: Unspecified → All
See Also: → 1360862
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.
Attachment #8866011 - Flags: review?(jfkthame) → review+
Pushed by
fix line heights to properly scale to requested size for color-bitmapped SFNTs. r=jfkthame
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
David, can you verify if this is fixed in the latest central?
Flags: needinfo?(dbaron)
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
Attachment #8866011 - Flags: approval-mozilla-esr52?
Attachment #8866011 - Flags: approval-mozilla-beta?
Hi Brindusa, is this issue you can help verify in the latest Nightly build? Thanks!
Flags: qe-verify+
Flags: needinfo?(brindusa.tot)
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: 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?
Flags: needinfo?(brindusa.tot)
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:
Flags: needinfo?(dbaron)
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.
Attachment #8866011 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
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-
Attachment #8866011 - Flags: approval-mozilla-esr52? → approval-mozilla-esr52-
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.
Duplicate of this bug: 1264458
I can reproduce this in Firefox 55 on openSUSE Tumbleweed, though it seems fixed in previous version.
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.
You need to log in before you can comment on or make changes to this bug.