GitLab

This CL is fixing the fallback selection for Emoji.

The problem got introduced here:
  https://chromium-review.googlesource.com/c/chromium/src/+/2075222

The original fallback implementation rely on
CTFontCreateForString(...) over the whole text of a run.
This was causing problem since the API on some versions of Mac
(see crbug/1036652) is broken with ignorable codepoints
(e.g. ZWJ and ZWNJ on arabic script).

The skia implementation is calling CTFontCreateForString(...)
but over a single codepoint. An algorithm is trying to find the
best match by taking the font with the most codepoints. While
this is working well for script, this is not working well for
emoji.

Emoji can have joiners (ZWNJ) between codepoints. The codepoints
that are joined can be on different blocks. Emoji can have a
presentation codepoint (<emoji> u+FE0E or <emoji> u+FE0F).

The fallback font was broken because the algorithm tries to find a
font for codepoints {u+2699, u+fe0f}. The codepoint u+fe0f is
an ignorable codepoint and was not taken into account while
choosing the fonts. The "Menlo" font was returned. The codepoints
u+2699 favor the textual representation and was not taking the emoji
color font.

The Apple Emoji Color font support both codepoints. We could take
into account the ignorable u+fe0f, but this is causing problem with
this example: {u+2699, u+fe0e}. There is no font that has both
of them. The selection can choose any font with {u+2699} or with
{u+fe0e}. Selecting font with only {u+fe0e} is also wrong. Same
issue can happen with the ZWNJ/ZWJ that can be found in emoji
sequence.

The proposal is to have a specific font for handling emoji.

Bug: 1099591
Change-Id: Id02952b2fa2c7b4052611c06c3b2a535e20600ae
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2429503
Commit-Queue: Etienne Bergeron <etienneb@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#810900}