screenshot taken on CrOS 63.0.3218.0 : the same sequence is rendered correctly. 

Noto Color Emoji on  Android 8.0.0 - OPR4.170623.009 should be identical to that included on CrOS. 

Harfbuzz and ICU are the same (bundled with Chrome). Could it be Skia? 

Deleted: Screenshot 2017-10-12 at 4.31.05 PM.png 737 KB

	Screenshot 2017-10-12 at 4.31.05 PM.png 737 KB View Download

> BTW, I found macOS Chrome is lot worse than Android Chrome with the Unicode Emoji Full chart.

I was mistaken. It's a font issue. Apple Color Emoji on macOS 10.12 does not cover new Emoji and sequences. So nothing is wrong on Mac Chrome except for the advance width issue. 

Can you describe further which advance width issue you see? Can we close this?

>  Can we close this?

??  This bug is still outstanding on Android-Chrome.  See the screenshot in comment 0. Female/Male sign is not applied. They're shown as separate glyphs on Android Chrome. 

> Can you describe further which advance width issue you see?

That's a separate issue from this. A lot of Emoji sequences (when rendered with a single glyph as they're supposed to) take up more horizontal space than a single glyph would as if there are multiple glyphs. 

> A lot of Emoji sequences (when rendered with a single glyph as they're supposed to) take up more horizontal space than a single glyph would as if there are multiple glyphs. 

Well, this is an artifact of viewing those sequences in a table column where some sequences do not have a font coverage and take up more horizontal space with multiple glyphs leading me to mistake sequences with the font coverage (being displayed with a single glyph) for taking more horizontal space as well. 

Simply put, there is no advance width issue on macOS Chrome. 

To avoid the confusion, let me say that the original issue as reported against Chrome-Android still stands. 

It'd be great if this issue could be taken care of before long. 

Similar problem is happening on Windows 10 when fonts like "Segoe UI Emoji" are used as a fallback to other font stacks.

For example on full-emoji-list.html page, adding "Arial" as the first font on .chars before all the other emoji fonts renders male/female signs separately.

Deleted: 24-143540119.png 36.5 KB

	24-143540119.png 36.5 KB View Download

Just chiming in to note that Chrome 68 on macOS also has this issue when Arial appears in the font stack.

I’ve created a test case demonstrating the error is Arial’s fault in particular: https://codepen.io/ticky/pen/MqWQOO

Think you'll be able to get to this anytime soon drott or should we find a new owner for it?

> Think you'll be able to get to this anytime soon drott or should we find a new owner for it?

I'll take a closer look at it when I have access to an Android device and I'll try to decide what the path forward could be. It looks like it works according to how our fallback is currently designed: If there is a font in the font chain that has the male/female signs they get rendered on their own, as they do not form a grapheme cluster with the rest of the emoji sequence (according to Unicode) and our fallback unit is a grapheme cluster. 

The workaround is always to specify the emoji font explicitly, but we can perhaps do better than that. 

I am not sure yet where we should override or special case this. Perhaps in our grapheme cluster analysis as part of shaping?

I think this issue is affecting more than just android. As others have said in this thread, Arial does seem to provoke this issue, but also Times New Roman, Impact, and others do as well. On chromeOS, fonts that don't affect macOS are affecting it too, such as Comic Sans.

I've attached some screenshots of a demo https://jsfiddle.net/4s0vcrf3/6/ for macOS and chromeOS. And it sounds like from comment 9, this is happening on windows with Arial and Segoe UI Emoji.

Deleted: chromeos.png 44.6 KB

	chromeos.png 44.6 KB View Download

Deleted: macos.png 24.4 KB

	macos.png 24.4 KB View Download

Thanks for providing the additional examples. The issue is well understood. I'll broaden the platform flags on this issue. It manifests on Android, as the primary font on Android seems to have character coverage for male and female signs. It does manifest in other situations where parts of the font stack before system fallback do have coverage for the male and female signs.

Solution proposal and follow-up discussion in https://github.com/harfbuzz/harfbuzz/issues/1159

 Issue 771510  has been merged into this issue.

 Issue 708604  has been merged into this issue.

 Issue 895497  has been merged into this issue.

Gated on https://chromium-review.googlesource.com/c/chromium/src/+/1268199

HarfBuzz roll to treat emoji sequences as HarfBuzz clusters, thus fixing fallback, with test landed in https://chromium-review.googlesource.com/c/chromium/src/+/1264519 

I'll request a merge once I will have verified this in Canary.

Thank you Dominik!

Thanks!

{phone}

On Fri, Oct 26, 2018, 13:04 eae via monorail <
monorail+v2.3593919584@chromium.org wrote:

Verified on Windows using 72.0.3595.0 Canary. On Android, 72.0.3595.0 was not available yet, verified with ToT build there. Requesting merge to 71.

This bug requires manual review: M71 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

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

This bug is very old bug reported on M63 on 10/17. Why it is critical to merge this change to M71 beta and how safe it is? 

Once I figured out in September that the bug has a common root cause with 3 duplicates (see the issue merges from comment #18), I realised this had been reported in additional forms and manifests in more scenarios. Also, luizp@ marked is as Hotlist-Partner-GSuite. For those reasons, I would consider it very useful, not necessarily super critical, to have it fixed already in 71. The change itself is a HarfBuzz roll, well covered by a layout test. I do not think it is particularly risky and not dependent or connected to other changes.

Approving merge to M71 branch 3578 based on comment #28 and #31. Please merge ASAP so we can pick it up for this week beta. Thank you.

Merged in https://chromium-review.googlesource.com/c/chromium/src/+/1306354 which unfortunately was reported to  issue 708604  due to the original commit's Bug: line. Sorry for the confusion.

Removing "Merge-Approved-71" label per comment #34.