Default emoji presentation should adhere to latest version of emoji-data.txt |
||||||||
Issue descriptionVersion: 53.0.2756.0 OS: Win10 (latest insider update which has updated Segoe UI Emoji 1.08) What steps will reproduce the problem? Open data:text/html;charset=utf8,%F0%9F%97%A3%F0%9F%95%B4%F0%9F%91%81%F0%9F%97%AF%F0%9F%95%B3%F0%9F%95%B6%F0%9F%9B%8D%F0%9F%95%B7%F0%9F%95%B8%F0%9F%8F%B5%F0%9F%8C%B6%F0%9F%97%BA%F0%9F%8F%94%F0%9F%8F%95%F0%9F%8F%96%F0%9F%8F%9C%F0%9F%8F%9D%F0%9F%8F%9E%F0%9F%8F%9F%F0%9F%8F%9B%F0%9F%8F%97%F0%9F%8F%98%F0%9F%8F%99%F0%9F%8F%9A%F0%9F%9B%B3%F0%9F%9B%A5%F0%9F%9B%A9%F0%9F%9B%8E%F0%9F%9B%8F%F0%9F%9B%8B%F0%9F%95%B0%F0%9F%8C%A4%F0%9F%8C%A5%F0%9F%8C%A6%F0%9F%8C%A7%F0%9F%8C%A8%F0%9F%8C%A9%F0%9F%8C%AA%F0%9F%8C%AB%F0%9F%8C%AC%F0%9F%8E%96%F0%9F%8E%97%F0%9F%8E%9E%F0%9F%8E%9F%F0%9F%8F%B7%F0%9F%8F%8C%E2%9B%B8%E2%9B%B7%F0%9F%8F%8E%F0%9F%8F%8D%F0%9F%95%B9%F0%9F%8E%99%F0%9F%8E%9A%F0%9F%8E%9B%F0%9F%96%A5%F0%9F%96%A8%E2%8C%A8%F0%9F%96%B1%F0%9F%96%B2%F0%9F%93%BD%F0%9F%95%AF%F0%9F%96%8B%F0%9F%96%8A%F0%9F%96%8C%F0%9F%96%8D%F0%9F%97%92%F0%9F%97%93%F0%9F%96%87%F0%9F%97%83%F0%9F%97%84%F0%9F%97%91%E2%9A%92%F0%9F%97%9C%F0%9F%9B%A1 What is the expected output? Like Firefox, all Emojis rendered with Segoe UI Emoji What do you see instead? It seems Emojis added on Unicode V7 are not detected as Emoji while those added on V8 are rendered correctly. You can compare https://commons.wikimedia.org/wiki/Emoji on Chrome and Firefox to see which ones are rendered with right font, perhaps there is some issue with the ICU API you are using for detecting Emojis.
,
Jun 6 2016
Thanks for the report! Without further font specifications Chrome generally renders Emoji as text presentation or emoji presentation according to: ftp://www.unicode.org/Public/emoji/2.0/emoji-data.txt and that is currently the intended behavior. Do you see deviations from this rule? That would be a bug, in which case, please reopen. If control over presentation type is needed, Chrome supports variation selectors for text and emoji presentation.
,
Jun 6 2016
U+1F54A is on that range (1F549..1F54E) but not rendered with right font. It seems the standard itself also updated, http://www.unicode.org/Public/emoji/3.0/emoji-data.txt (v3) has 1F3D4..1F3DF which was not on the previous so I think Chrome misses something here (generally I believe it is better to future proof this and pass everything to Emoji font first, just like Firefox).
,
Jun 6 2016
Thanks, we might need to update to v3 of emoji-data in our Character functions. > (generally I believe it is better to future proof this and pass everything to Emoji font first, just like Firefox). I disagree here. Variations selectors, or in the future, the generic emoji font: https://drafts.csswg.org/css-fonts-4/#extended-generics are an option for specifying explicit emoji display. What we could do in the meantime as well is to prefer emoji display whenever any common emoji font name is used. However, for the default case, no extra font specified and not other indication that Emoji presentation is requested, we should follow http://www.unicode.org/reports/tr51/
,
Jun 6 2016
,
Jul 19 2016
,
Jul 19 2016
,
Jul 19 2016
,
Dec 13 2016
Issue 673372 has been merged into this issue.
,
Dec 15 2016
Chromium has Emoji 4.0 final (from ICU 58). Emoji 5.0 is still proposed draft although it'll be released pretty soon.
,
Jan 11 2017
Hmm... The first few characters in the url given in the bug report are U+1F5E3 U+1F574 U+1F441 U+1F5EF U+1F573 U+1F576 and their default presentation form is Emoji according to Emoji 4.0 data http://www.unicode.org/Public/emoji/4.0/emoji-data.txt So, why are they rendered with an non-Emoji font? Actually, this is not reproducible on Mac and Linux/CrOS (with Noto Color Emoji). This is a Windows-specific issue.
,
Sep 16 2017
,
May 31 2018
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by ebra...@gnu.org
, Jun 6 2016123 KB
123 KB View Download