Wrong emoji presentation when Arial is in the CSS font stack
Reported by
aravi-su...@zendesk.com,
Nov 8
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36 Example URL: Steps to reproduce the problem: 1. Visit the URL using Chrome on Mac 2. Observe the column of ☺️️ emojis. This is the 8th column on the first row. 3. Remove Arial from the font stack for .font1 (in the CSS panel) and observe the same emojis again. What is the expected behavior? The first element in each set of 3 characters should use a color emoji glyph if available in the CSS font stack. The second element should use an emoji or symbol glyph depending on the Emoji_Presentation value in Unicode TR51 Annex A and availability of each glyph in the CSS font stack. The third element should use a monochrome symbol glyph if available in the CSS font stack. Explanation: The first element has an emoji presentation selector character after it, while the second has no presentation selector and the third has a text presentation selector. What went wrong? The following characters: ☺️️ ‼️️ ↕️️ ↔️️ ©️️®️️ ™️️ ♠️️ ♣️️ ♥️️ ♦️️display using the monochrome symbol glyph even when the emoji presentation selector is used. Removing Arial from the font stack fixes this problem. Does it occur on multiple sites: N/A Is it a problem with a plugin? N/A Did this work before? N/A Does this work in other browsers? N/A Chrome version: 70.0.3538.77 Channel: stable OS Version: OS X 10.13.6 Flash Version: A similar issue was also observed in Firefox 64 beta 7, affecting even more characters. In Firefox, only removing Arial from the font stack alone does not fix this, but removing Helvetiva Neue and sans-serif fix some but not all characters.
,
Nov 8
,
Nov 8
,
Nov 9
Able to reproduce the issue on reported chrome version 70.0.3538.77 also on latest chrome 72.0.3605.0 using Mac 10.13.6 & 10.14.0, Ubuntu 14.04 and Windows 10. Same behavior is seen on M60(60.0.3112.113) hence considering it as non-regression and marking it as Untriaged. Thanks!
,
Nov 9
This is working as intended. The way font fallback works is that it picks the first font in the font-family list that can render the character. ☺️️ can be rendered by Arial. None of the other characters can be rendered by any of the fonts listed in the font-family list, hence triggering the browser fallback behavior which correctly picks "Segoe UI Emoji". To get the desired behavior you'll need to either list all of the relevant emoji fonts in font-family or make sure that none of the fonts listed have coverage for any of the emoji characters. CSS Fonts Level 4 introduces a font-variant-emoji property that can control this behavior. No browser has implemented this as of yet however.
,
Nov 10
The bug occurs on a Mac. I believe font fallback should pick the first font in the font-family list that can render the *glyph* (not character). Here, the glyph should be selected based on two characters, U+263A (☺) and U+FE0F (the unicode variation selector). "Arial Unicode MS" (not "Arial") does have a glyph defined for U+263A (glyph no. 4373), but I do not believe it has one for this combination of base character and variation selector. More to the point, this theory does not explain the behaviour of U+2639 (☹) - this character also has a glyph in Arial Unicode MS (no. 4372), but chrome still displays the correct color glyph from "Apple Color Emoji" when the U+FE0F emoji variation selector is used. Here is a reduced test case with only these two characters, with and without the emoji/text presentation selectors: https://codepen.io/aravindet/pen/RqRzPG Note that Safari renders this correctly. It uses the color glyph by default or when forced, and the monochrome glyph from Arial Unicode MS when the U+FE0E text presentation selector is used. Chrome and Firefox render this incorrectly. I have not tested with IE/Edge. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by aravi-su...@zendesk.com
, Nov 8