New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 15 users

Issue metadata

Status: Assigned
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug

Sign in to add a comment

Issue 596223: M49 Regression: Emoji layout width too small (or character too large) on non-2x

Reported by, Mar 19 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36

Example URL:

Steps to reproduce the problem:
0. Use a Mac, and set your display to non-2x resolution.
1. Load

What is the expected behavior?
Same spacing between
Screen Shot 2016-03-18 at 16.57.58.png
4.3 KB View Download

Comment 1 by, Mar 19 2016

The “Chromium issue wizard” truncated my report!!!

Same spacing between

Comment 2 by, Mar 19 2016

Ah! My comment is truncated too.

Same spacing between [emoji] and the two “+” signs.

[emoji] overlaps with the “+” after it.

From M48 to M49, is fixed for 2x display and this bug is introduced for non-2x display.

Comment 3 by, Mar 19 2016

Components: -Blink Blink>Fonts

Comment 4 by, Mar 23 2016

Status: Assigned (was: Unconfirmed)

Comment 5 by, Mar 24 2016

Ben, I believe this is a Skia issue, could you comment?

Comment 6 by, Mar 25 2016

With Chrome 49.0.2623.87 (stable) on a non-retina I actually see nothing drawn for the emoji in the web page (I see the correct one in the edit box). In 51.0.2687.0 canary and current tip of tree Chromium I see the correct emoji drawn and it doesn't overlap anything and seems the right size. (This is all on a MacPro.)

What version of osx is this? Which hardware? Is this a retina display running at 1x? Can you try with Canary on this setup and see if there is a difference?

Comment 7 by, Jun 12 2016

This problem exists for a long time, Emoji in Chrome the letter spacing is too small.
36.9 KB View Download

Comment 8 by, Dec 14 2016

Due to staring at several other issues, I think I know why this happens. The issue is measuring with one typeface but drawing with another. The most likely way for this to happen is when a typeface is found, the code stashes the typeface name somewhere (instead of the typeface itself) and then does a lookup based on the name later (trying to get the same typeface back). On a Mac, this will almost always result in the different emoji seen here because looking up a typeface by a name some typeface produced is quite unlikely to produce the same typeface (and in some cases is undefined). This also (as one would expect) works poorly with caching.

I expect this is seen much less in recent versions of Chromium because there is now much less of this behavior (trying to 'serialize' and 'deserialize' a typeface based on name alone). I'm not currently seeing this on my non-retina macOS 10.12.1 with Chrome 57.0.2949.0. Is anyone still running into this issue? If so, please provide any details you may have.

Comment 9 by, Dec 15 2016

I think it might (also) have something to do with metrics scaling in CoreText shaping: From one ebraminio's contribution to HarfBuzz it seems that scaling up from font size 16 does not work so well for emoji, compare: - when that is changed to always using a CTFont at the right size, emoji spacing looks better.

Comment 10 by, Dec 15 2016

Interesting HarfBuzz issue. Note that Skia needs to go out of its way to only use CGFont (or a CTFont created directly from a CGFont), because drawing a CTFont at various sizes (including changing size through a transform) can cause an entirely different underling font to be used. See comments in and around Skia's SkFontHost_mac.cpp#ctfont_create_exact_copy for some details on this behavior.

Comment 11 by, Dec 15 2016

I also have submitted that as a test patch to Chromium would be nice to check that out.

Comment 12 by, Dec 19 2016

Siulung@, what do you mean by non 2x resolution? I've tried to reproduce your steps with all scaling settings on a Retina MacBook Pro but cannot reproduce the + overlap on top of the emoji. (compare emoji_search_stable.png).

Ebrahim, I ran this with your CL applied, the emoji spacing in this case looks two wide to me, second screenshot.
19.0 KB View Download
50.4 KB View Download

Comment 13 by, Dec 19 2016

I think what Siulung@ is referring to is non 2x DPI (LoDPI) macOS as I have the same issue as the reporter on my non-retina MacBook.

An interesting thing I faced while my little tests, hb-coretext custom constructors (hb_coretext_face_create, and my not merged hb_coretext_face_create_from_ct_font) fonts are acting differently than default harfbuzz constructed fonts on glyph metric things, perhaps this is related to the issue we have here or maybe not.

Comment 14 by, Dec 19 2016

Thanks - I'll try experimenting with setting a forced device scale factor for reproducing this.

Comment 15 by, Jan 28 2017

I am having a similar issue, which I was going to file separately, until I found this issue.

For my part, I am running Chrome 56 on Mac OS X 10.12.2, on a non-Retina Mac.

I prepared a fiddle that demonstrates my issue; it seems to be most visible when the font is 16px or smaller.

Expected Results:
- The <span> that contains each emoji is rendered wide enough to contain the whole character.

Actual Results:
- At smaller font sizes, the emoji is rendered larger than the enclosing <span>.
Screen Shot 2017-01-27 at 4.03.29 PM.png
16.7 KB View Download

Comment 16 by, Jun 20 2017

I took a quick look into this. At least a little bit of this is fixed on the browser side. It used to be that the browser would often measure with one font and draw with a completely different font and could end up with strange layout like this.

As far as the Blink layout side goes, I cannot reproduce this issue when using version 10 of the AppleColorEmoji font, but I can reproduce when using version 12 of the AppleColorEmoji font. It may be the case that Apple relatively increased the size of the smaller emoji bitmaps (to enhance legibility) but this means the bitmaps no longer linearly scale. This may be breaking some assumption around linear scaling of text (which of course text doesn't do).

Comment 17 by, Jun 20 2017

Super simple local reproduction

<span style="font-family:Helvetica;font-size:14px;background-color:green;">feels 💙</span>


Comment 18 by, Jan 3 2018

This is more noticable for me on my non-retina external screen, but these emoji's still overlap on the main (retina) screen.

Compare this to the flawless rendering from iMessage.
Screen Shot 2018-01-02 at 19.20.08.png
5.8 KB View Download
Screen Shot 2018-01-02 at 19.20.17.png
8.1 KB View Download
Screen Shot 2018-01-02 at 19.21.43.png
6.0 KB View Download

Comment 19 by, Feb 14 2018


Comment 20 by, Feb 19 2018

I *think* latest AppleColorEmoji has a trak table. I might be wrong.

Comment 21 by, Feb 19 2018

Yes, it has.

Comment 22 by, Feb 19 2018

Ok then, we need to figure out how to instantiate it such that CoreText does traking.  See:

I couldn't see any constant immediately for emoji font.  I'll ask Ned.

Comment 23 by, Feb 19 2018

Looks like we have to shape an emoji char with system font and fallback enabled, and use the resulting CTFont as a Apple Color Emoji CTFont that applies traking.

Comment 24 by, Feb 24 2018

Now harfbuzz has [an initial state] `trak` implementation which I did in hope this to be fixed sooner :)

Comment 25 by, Nov 28

Can anyone that still can reproduce this can test the most recent Chrome canary to see if this fixed?

Comment 26 by, Nov 28

Using Chrome 72.0.3624.0 I took the below screenshots.

As you can see the non-retina version is now working pretty well (using iMessage as a baseline), but when I drag the window to my retina monitor, the emojis are now too widely spaced.

In all of these screenshots there is no space between the emojis, and one space after the second emoji before the text.

🎉🎉 for example
Screen Shot 2018-11-28 at 08.41.51.png
5.4 KB View Download
Screen Shot 2018-11-28 at 08.41.56.png
13.0 KB View Download
Screen Shot 2018-11-28 at 08.48.37.png
5.9 KB View Download
Screen Shot 2018-11-28 at 08.48.52.png
8.6 KB View Download

Sign in to add a comment