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

Issue 774336 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Emojis Render as Multiple Glyphs in RTL with Font Fallthrough

Project Member Reported by nreiter@google.com, Oct 13 2017

Issue description

Chrome Version       : 61.0.3163.100
OS: tested on Linux, as well as OS X with a larger repro case
URLs (if applicable) : Test case attached

What steps will reproduce the problem?
1. Open the attached test file 

What is the expected result?
Emojis composed of multiple unicode codepoints should correctly combine (e.g. the https://emojipedia.org/female-technologist/ should show as a single visual glyph)

What happens instead of that?
The emoji renders with the (visible) individual glyphs (e.g. woman + computer, with computer rendering to the left, zero width joiner invisible). This seems to apply to all emoji requiring multiple codepoints, including the family and profession ones. 

Please provide any additional information below. Attach a screenshot if
possible.

Screenshot and test case attached.

When removing the <link /> to the Roboto font, the glyphs appear to combine correctly, suggesting this may have something to do with the fallback to the NotoColorEmoji font in RTL.

UserAgentString: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36



 
emoji_rtl.html
511 bytes View Download
emoji_incorrect_rtl.png
14.0 KB View Download
Cc: ranjitkan@chromium.org
Components: UI>Internationalization>RTL
Labels: -Type-Bug -Pri-3 hasbisect-per-revision Needs-Triage-M61 M-63 OS-Mac OS-Windows Pri-1 Type-Bug-Regression
Owner: kojii@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce the issue on Windows 10, Mac 10.12.6, Ubuntu 14.04 using chrome version 61.0.3163.100. Issue is a regression and is broken in M56. below are the bisect details for the same:

Bisect info:
============
56.0.2909.0 - Good build
56.0.2910.0 - Bad build

Using per-revision bisect got the below change log:

Change LOG: https://chromium.googlesource.com/chromium/src/+log/4377f6270a5f3a53d2bb56f5a276c243aa36f7e8..ea599b0be3e912060db3a4a2b3bf2510c114775c

Change URL: https://chromium.googlesource.com/chromium/src/+/ea599b0be3e912060db3a4a2b3bf2510c114775c

@ kojii: Assigning to you, request you to please take a look into it. Please help us to find an owner if not with respect to your change.

Thanks.!

Comment 2 by kojii@chromium.org, Oct 13 2017

Labels: allpublic
allpublic confirmed with the opener.

Comment 3 by kojii@chromium.org, Oct 13 2017

Cc: kojii@chromium.org
Owner: drott@chromium.org
drott@, could you mind to have a look? The mentioned CL fixed the directionality of the Emoji (or any surrogate pairs), does that affect Emoji sequence code?

Comment 4 by kojii@chromium.org, Oct 13 2017

Components: -UI>Internationalization>RTL Blink>Fonts>Emoji

Comment 5 by drott@chromium.org, Oct 13 2017

At least, 
$ hb-shape NotoColorEmoji.ttf --direction=rtl "👩‍💻" 
with the font downloaded from the URL in the test file seems to work.

I will take a look, but it may take some time as I'd like to finish one or two things before I get to this one. If you're up for writing a HarfBuzzShaperTest for this, Koji, that might already get us additional insights.

Comment 6 by nreiter@google.com, Oct 13 2017

Of note, using the NotoColorEmoji.ttf font directly appears to work as expected. It's only when 'Roboto' is specified as a primary font first that the issue manifests.

e.g. font-family: NotoColorEmoji; /* Single glyph */
     font-family: Roboto, NotoColorEmoji; /* Splits */

Comment 7 by e...@chromium.org, Nov 30 2017

drott/kojii: Did either of you get a chance to look into this?

Comment 8 by drott@chromium.org, Dec 1 2017

I haven't had a chance to look further than #5 so far.

Comment 9 by kojii@chromium.org, Dec 6 2017

Labels: -OS-Windows -OS-Mac
A couple of notes:
* Does not reproduce on Windows (can't render NotoColorEmoji at all, I believe this is by design for now.)
* Does not reproduce on Mac, both render correctly.
* Reproduces on Linux, only when 'font-family' has some fonts before 'NotoColorEmoji' (in this case, Roboto, but Arial can do too.) Making 'NotoColorEmoji' fixes the problem.

Looks like font cascading problem?
Note, on Mac, it fails to decode the downloaded font (error in console) and renders with Apple Color Emoji.

On Linux, LTR uses 1 glyph from Noto Color Emoji while RTL uses 3 glyphs from Noto Color Emoji.

On Windows, it can't render, but it uses 1 glyph form Noto Color Emoji for both LTR and RTL.

Comment 11 Deleted

Sign in to add a comment