New issue
Advanced search Search tips

Issue 810512 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac , Fuchsia
Pri: 2
Type: Bug


Participants' hotlists:
layout-backlog


Sign in to add a comment

Fallback font logic around emoji ZJW sequences could be better

Project Member Reported by n...@chromium.org, Feb 8 2018

Issue description

Chrome Version: 64.0.3282.119
OS: OSX

What steps will reproduce the problem?
Go to http://output.jsbin.com/cicakufumi and look at the output. The difference between the two lines is that the first one forces the font-family to Arial, and mis-renders the 🙇‍♀️ ("bowing woman") emoji.

What is the expected result?
You should see the correct glyph in both cases.

This was originally filed as a harfbuzz bug (https://github.com/harfbuzz/harfbuzz/issues/217), but @eae says it should maybe be fixed in Chrome. If I understood correctly, the problem is that the fallback algorithm says "if this glyph can't be rendered at all in Arial, move down to the native Emoji font", but since it can be partially rendered in Arial (bowing man), then it declares it a success and sticks with it (even though that is not the correct glyph)


 

Comment 1 by e...@chromium.org, Feb 8 2018

Components: -Blink>Fonts>Emoji
Labels: -Pri-3 OS-Android OS-Chrome OS-Fuchsia OS-Linux OS-Windows Pri-2
Status: Available (was: Untriaged)
Somewhat similar to 591346 in that both cases would benefit from cluster-based fallback.

For emoji in particular we might be able to modify SymbolsIterator to take the entire emoji sequence into account.

Comment 2 by drott@chromium.org, Feb 9 2018

Cc: behdad@chromium.org
Thanks for the report, agree this could be better.

SymbolsIterator does not split the sequence and sends it to HarfBuzz as a whole. For determining what a grapheme cluster is in fallback, we use HarfBuzz cluster information. It seems that Emoji ZWJ sequences do not come back as one cluster from HarfBuzz, so since Arial is selected as primary font and Arial has coverage for ♀️, U+2640 FEMALE SIGN is rendered using Arial, then fallback is performed, and the emoji sequence gets split. 

Grapheme cluster formation is based on ICU/Unicode data, "HarfBuzz cluster" formation is based on a mix of that plus OpenType layout information. 

Ideally, Unicode data should help with identifying emoji sequences as cluster, but I am not sure whether that's still possible given the messy way, emoji sequences are formed.

Thoughts, Behdad?


I thought we send the emoji sequences directly to the emoji font. No?

Comment 4 by drott@chromium.org, Feb 12 2018

We send them to the emoji font as the first fallback font, we don't preempt the specified styling, which is Arial in this case. Since we start to support web color fonts, we have to try the font-family: list first.

Sign in to add a comment