Thanks for filing the issue!

Unable to reproduce the issue on reported chrome version 64.0.3282.186 and on the latest chrome canary 66.0.3356.0 using MacBook Pro 10.13.1 with the below mentioned steps.
1. Launched Chrome
2. Navigated to https://github.com/arpith/test-emoji
3. Later inspected the page and typed and emoji followed by a character.
We are able to see similar spacing in all the chrome versions checked i.e., M60(60.0.3072.0) canary M66(66.0.3356.0) in comparison with reported version. Attaching the screen cast of the same.

@Reporter: Could you please have a look at the screen cast and let us know if we have missed anything in the process of reproducing the issue. 

Deleted: 816978.mp4 2.0 MB

	816978.mp4 2.0 MB View Download

Hi 😊!
Can you confirm that this spacing is preserved on the default font size as well? (I've attached a screen cast to explain what I mean).

The left side of the screen (github.com/arpith/test-emoji) is zoomed, while the right side of the screen (inspector) starts with large font size (similar to your screen cast) and then reduces to the standard font size. 

For comparison, I'm using 😊" and /" to see how character spacing is preserved (or not) when the font size goes from large to regular.

Deleted: Emoji spacing.mov 24.7 MB

Emoji spacing.mov 24.7 MB Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

@Reporter: The screen cast provided in comment#3 shows almost similar behaviour i.e., while zooming out little spacing variation in both M64 and M66 are the same. As ET team is not clear about your first statement "Can you confirm that this spacing is preserved on the default font size as well?" could you please elaborate on this, which would be highly helpful for further triaging.

Thanks!

Hi 😊! Thanks for getting back on this. The screen cast was to demonstrate the space that appears between an emoji and a following character when the font size is not large. This issue is not present for the second set of characters (non-emoji).

In your first reply to the issue (comment 2) you had attached a screencast with a large font size (where this issue is not present). 

My question was whether you were able to reproduce this issue (or not) with the default font size in the inspector (or, alternatively, with the font size on github.com/arpith/test-emoji).

To clarify further, I am experiencing this issue on Chrome 64 and 66. Chrome 63 did not have this issue (https://www.browserstack.com/start#os=OS+X&os_version=High+Sierra&browser=Chrome&browser_version=63.0&zoom_to_fit=true&full_screen=true&url=https%3A%2F%2Fgithub.com%2Farpith%2Ftest-emoji%2Fblob%2Fmaster%2FREADME.md&speed=1)

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Here is a screen cast that shows Chromium 63, Chrome 64 and Chrome Canary 66 one after the other. In each version, the inspector is set to the default font size. 

The differences to be noted - in 63, both the webpage (github.com/arpith/test-emoji) as well as the inspector show no space between the emoji and the next character.

In 64 and 66, this is no longer the case. There is a gap between the emoji and the following character (both in the webpage as well as the inspector).

Hope this helps 😊!

Deleted: Emoji Trailing Whitespace.mov 16.9 MB

Emoji Trailing Whitespace.mov 16.9 MB Download

Able to reproduce the issue on mac 10.13.3 using chrome reported version #64.0.3282.186, latest beta #65.0.3325.106 and latest canary #67.0.3361.0. Issue is not seen in OS-Win and OS-linux.

Bisect Information:
=====================
Good build: 64.0.3257.0
Bad Build : 64.0.3258.0

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/5877a5b752d3cb6a84b07caf92eb69eecc0854ef..487f920d800195ee2d5de599ac0f647720627dc4

From the above change log suspecting below change
Change-Id: Ibc33c6da69a4401ed590b349773ae154db4fd0d7
Reviewed-on: https://chromium-review.googlesource.com/718860

drott@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.
Note: Adding stable blocker for M-65 as it seems to be a recent regression and stable will be moving to M-65 within ~1-2 weeks.

Thanks...!!

Any update on this?

Have you had a chance to look into this yet drott?

Not yet, I'll take a look. The reproduction page is on Github, which also does some custom emoji image replacement fallback in some cases. 

arpith@, do you see a slightly too wide advance width in the first line of this test page, too? https://codepen.io/anon/pen/LdxgKO 
What do you see in the second line?

Related, and I need to check how this plays into this issue. We currently do not support tracking for the Apple Color Emoji font as we there is no CoreText API to activate it. The Apple Color Emoji font has a tracking table:

  <trak>
    <version value="1.0"/>
    <format value="0"/>
    <horizData>
      <!-- nTracks=1, nSizes=5 -->
      <trackEntry value="-1.0" nameIndex="290">
        <track size="0.0" value="0"/>
        <track size="9.0" value="46"/>
        <track size="16.0" value="46"/>
        <track size="22.0" value="30"/>
        <track size="29.0" value="0"/>
      </trackEntry>
    </horizData>
    <vertData>
      <!-- nTracks=0, nSizes=0 -->
    </vertData>
  </trak>

This tracking table would add 46 font units of spacing at a font size > 16px. 

We also previously had an issue with too narrow emoji advance width, see  issue 784780 .

PS: The CL https://chromium-review.googlesource.com/c/chromium/src/+/718860 was crucial for improving character spacing/tracking on Github with Mac System fonts. So it may be that there is no change to the emoji itself, but more space added before the " (which is displayed in the .SF NS Text font).

Hi 😊 Thanks for looking into this!
I'm attaching a screenshot of the test page. Note that I have added a test without the double quotes (") that follow the emoji, since this seems to be confusing the issue. The test has a background color for the emojis so that the extra spacing is visible.
The new link is https://codepen.io/anon/pen/vRxOxZ

This is how I came across this issue, it is no longer possible to center emojis in an element (without resorting to Chrome specific hacks). This means that elements with emojis in them, for example emoji reaction buttons, look different from other browsers.

Out of curiosity, how were emoji fonts handled in Chrome 63 for MacOS? Is it possible to fallback to that just for this font (at least until this issue is resolved)? 

Once again, thanks for your work!

Deleted: Screen Shot 2018-03-20 at 12.35.07 PM.png 337 KB

	Screen Shot 2018-03-20 at 12.35.07 PM.png 337 KB View Download

Have you had a chance to look into this drott? IT's currently listed as a P1 regression so either we need to prioritize it, or if it isn't a top priority change it to a P2.

At 24px spacing between emoji and the system font, and the spacing between emoji and the serif font is identical between Safari and Chrome. At smaller font sizes, aligned by the quotes, it seems that in Chrome the emoji are rendered smaller than in Safari, at the same font size, which then leads to the perceived effect of having too much whitespace to the next character.

I am attaching an image where the light opacity overlay is the Safari rendering, aligned with Chrome at the quote marks, showing that Safari has bigger emoji at identical specified pixel font sizes.

Lowering priority to 2 as the impact is Mac only and does not disturb general legibility too much. We should clarify what's going on here compared to what Safari + CoreText compute for advances and what they rasterize. Firefox has different (narrower) spacing than Safari, and seems to display smaller emoji as well compared to Safari - which is similar to Chrome.

Deleted: emoji_size_differences.psd 278 KB

emoji_size_differences.psd 278 KB Download

Deleted: emoji_size_differences.png 41.6 KB

	emoji_size_differences.png 41.6 KB View Download

The size difference is curious.

Re enabling trak table for Apple Color Emoji, according to Ned that can be done by shaping an emoji character with CoreText and grabbing the CTFont that gets assigned to it... If we do that once and cache it in Blink, we can then pass it to HarfBuzz.  Too much work... Maybe easier to finish native AAT support in HarfBuzz instead.

https://codepen.io/anon/pen/KRmBYZ is a codepen that shows the amount of whitespace at the right side of the rendered emoji. This is particularly bad at font sizes between 10 and 20px (including).

Deleted: emoji_white_space.png 57.5 KB

	emoji_white_space.png 57.5 KB View Download

Just wanted to add that currently emojis are not center aligned properly with certain (small?) sizes. I'm guessing it's related to this bug.

https://codepen.io/chengyin/pen/XyeYrY

(The 16px one is the one with issue.)


CHROME VERSION
70.0.3538.102

OS VERSION
Mac OS X: 10.14.1

Deleted: Screen Shot 2018-11-19 at 12.51.07 AM.png 85.6 KB

	Screen Shot 2018-11-19 at 12.51.07 AM.png 85.6 KB View Download

This is still reproducible even after switching to HarfBuzz AAT. Looking closer at the difference between Safari and Chrome, it appears as if Safari places the painted emoji in the middle of the advance width, while Chrome places it more to the left.

Deleted: left_chrome_safari_right.png 116 KB

	left_chrome_safari_right.png 116 KB View Download

Humm.  Looks like the x_offset of the glyph is being ignored.  Which is really hard to imagine for me.

BTW, Ebrahim pointed this out: what's the "FontCache scaling" flag thing?  Where can I read about that?

Oh.  Humm.  It's worth checking where the advance width is coming from.  Is it from HarfBuzz instead of Skia?  Is that what we use for advance width now?

It looks like the difference is not so much the placement within the advance width, but that Chrome seems to be rendering smaller emoji than Safari.  The advance width comes from the hmtx table and linearly scales and is clear.  The image however should be chosen from one of the strikes.  The algorithm I implemented in cairo, fontconfig, and harfbuzz, is to pick the strike with smallest size, that is not less than requested size, or the largest size if all are smaller than requested.  It's worth checking what Skia is doing, and guesswork what CoreText is doing.