Fix font fallback for Emoji on Mac
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}
Showing
Please register or sign in to comment