New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 491556 link

Starred by 12 users

Issue metadata

Status: Fixed
Owner: ----
Closed: Jul 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

Variation selectors U+FE0F and U+FE0E not taken into account when selecting a font.

Reported by papierk...@live.com, May 23 2015

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/600.6.3 (KHTML, like Gecko) Version/8.0.6 Safari/600.6.3

Example URL:

Steps to reproduce the problem:
1. Open a page that contains for instance U+2712 U+FE0F and  U+27A1 U+FE0F

What is the expected behavior?
An Emoji nib and an Emoji arrow should show up.

What went wrong?
The glyphs are not appearing as Emojis but in their "normal" form.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? No 

Does this work in other browsers? Yes 

Chrome version: 45.0.2410.0  Channel: canary
OS Version: OS X 10.10.3
Flash Version: 18.0.0.144

Maybe related to https://code.google.com/p/chromium/issues/detail?id=468349.
 
Screen Shot 2015-05-23 at 18.41.47.png
35.6 KB View Download

Comment 1 by papierk...@live.com, May 23 2015

The problem can be easily reproduced by visiting: http://www.fileformat.info/info/emoji/browsertest.htm

Comment 2 by tkent@chromium.org, May 25 2015

Labels: -Cr-Content Cr-Blink-Fonts Cr-Blink-Fonts-Emoji

Comment 3 by js...@chromium.org, Oct 13 2015

Cc: drott@chromium.org kojii@chromium.org e...@chromium.org
Labels: -OS-Mac OS-All
Summary: Variation selectors U+FE0F and U+FE0E not taken into account when selecting a font. (was: Variation character U+FE0F not working with most glyphs)
+kojii who added VS support for CJK Ideographs. 

On Chrome OS and Android, the following is another way to reproduce the issue.
(On Mac use 'Apple Color Emoji' in place of 'Noto Color Emoji') 

1. 
data:text/html,☺️ /* Emoji variation selector */ 

2. 
data:text/html,☺︎ /* Text VS */ 

3. 
data:text/html,<span style="font-family: Arial, Noto Color Emoji;">&#x263A;&#xFE0F;</span>

4.
data:text/html,<span style="font-family: Arial, Noto Color Emoji;">&#x263A;&#xFE0E;</span>


5. 
data:text/html,<span style="font-family: Noto Color Emoji, Arial;">&#x263A;&#xFE0F;</span>

6. 
data:text/html,<span style="font-family: Noto Color Emoji, Arial;">&#x263A;&#xFE0E;</span>

7. 
data:text/html,<span style="font-family: Noto Color Emoji">&#x263A;</span>

8. 

data:text/html,<span style="font-family: Arial;">&#x263A;</span>



#1, #3, #5, #7 should be identical (color emoji)
#2, #4, #6, #8 should be identical ('text' glyph from Arial or equivalent non-emoji font). 

Alternatively, one can go to http://unicode.org/emoji/charts/full-emoji-list.html and look for U+263A. The browser column (3rd column) shows a regular glyph (non-emoji) in Chrome on Mac or Chrome OS/Android (or Linux with FreeType 2.6 + Noto Color Emoji installed) while Safari on Mac/iOS shows emoji. The cell has U+263A followed by U+FE0F. The font-family (font-stack) starts with 'Times New Roman' which does cover U+263A. Even though TNR covers U+263A, it's skipped by Safari because of U+FE0F (emoji VS) and uses 'Apple Color Emoji' instead. 


Comment 4 by js...@chromium.org, Oct 13 2015

Cc: js...@chromium.org

Comment 5 by js...@chromium.org, Oct 14 2015

Cc: markda...@google.com
Status: Available

Comment 6 by bcmi...@google.com, Jul 1 2016

Also seeing this on ChromeOS.  100% reproducible.

Enter the following in the address bar:

    javascript:alert("\u2B1C\uFE0E")

Expected: white large square
(http://unicode.org/emoji/charts/emoji-variants.html#2b1c)

Actual: blue large square
(Same output as for javascript:alert("\u2B1C\uFE0F"), which should select the other variant.)

Comment 7 by bcmi...@google.com, Jul 1 2016

Version 52.0.2743.49 beta (64-bit)
Platform 8350.38.0 (Official Build) beta-channel panther
Firmware Google_Panther.4920.24.26

Comment 8 by drott@chromium.org, Jul 1 2016

The http://unicode.org/emoji/charts/emoji-variants.html#2b1c page renders exactly as expected for me. This bug does not apply to Emoji any more, only for fallback in other VS cases, compare 580074. We do have open issues regarding variation selectors for doing CJK fallback, and we should update this bug with details on that.

I believe you're encountering a separate issue for the javascript:alert case. Could you file a separate issue for that?

Comment 9 by bcmi...@google.com, Jul 1 2016

> The http://unicode.org/emoji/charts/emoji-variants.html#2b1c page renders exactly as expected for me.

That page isn't rendered by the browser: the glyphs there are sample images, not a browser test table.


> This bug does not apply to Emoji any more, only for fallback in other VS cases, compare 580074.

That bug doesn't seem to have anything to do with this one?  In particular, it doesn't even mention variation selectors.

> That page isn't rendered by the browser: the glyphs there are sample images, not a browser test table.

I'm sorry, I should have looked closer. I tested on Mac where the rendering is identical. I created http://codepen.io/anon/pen/JKNBqd for testing this, where it renders correctly for me: First is text presentation, second is emoji presentation, third is emoji presentation. As expected according to ftp://www.unicode.org/Public/emoji/2.0/emoji-data.txt

> That bug doesn't seem to have anything to do with this one?  In particular, it doesn't even mention variation selectors.

Again, sorry that the answer was a bit brief. SymbolsIterator, which this bug was about, implements the emoji font selection taking the variation selector into account:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/fonts/SymbolsIterator.cpp?sq=package:chromium&l=93






Perhaps the current emoji bug is ChromeOS-only, then (see attached screenshot).
Screenshot 2016-07-01 at 13.17.00.png
47.9 KB View Download
Filed  http://crbug.com/625210  so that the ChromeOS issue can be triaged separately.
Also reproducible in Chrome on Android.

(On what platforms is emoji rendering actually fixed?  Just Mac/Windows/Linux?)
Screenshot_20160701-132514.png
87.6 KB View Download
Android issue filed as http://crbug.com/625212.
Thanks for filing those, I commented on the Chrome OS bug. In Android, it should be fixed by switching to the complex text path, which we plan to do as soon as possible, that is given that a font that has the text presentation square is available.
Project Member

Comment 16 by sheriffbot@chromium.org, Jul 3 2017

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 17 by e...@chromium.org, Jul 6 2017

Status: Fixed (was: Untriaged)
I'm having problem with Variation Selector 15 (&xFE0F;), where Chrome inconsistently displays the variation. 

In the screenshot below, it is seen having its "emoji" form. However, when I first appended the VS15 character, I intended it to revert back to its original B&W unicode form; and it indeed changed back at first, but when I left and return later, it switched back to its emoji form while nothing has changed.
screenshot.png
34.0 KB View Download

Sign in to add a comment