Missing emoji color variants of ☝️ and ✌️

[guoyunhe]

[dougfelt]

what platform are you viewing this on?

[guoyunhe]

@dougfelt Linux (openSUSE Tumbleweed) with Chromium. webpage https://eosrei.github.io/emojione-color-font/full-demo.html

[polarathene]

I can confirm this with Firefox 69 and Chrome 77 with Linux on Manjaro KDE(latest).

I've not yet adjusted my fontconfig to ensure "Noto Color Emoji" is prioritized. The "eosrei" site assigns the font-family "EmojiOne Color" followed by sans-serif. While getemoji.com assigns "Segoe UI Emoji".

Chrome

In my case quite a few of the other hand glyphs surrounding the problem ones @guoyunhe is referencing are vertical rectangle pairs(wrong fallback font selected for initial or both parts?), some emoji render(fallback to Noto Color Emoji successfully), and these two ( ☝️🏻 , ✌️🏻 ) render a black/white outline(from Noto Sans Symbols2) which seems to be taking priority over Noto Color Emoji, I guess it matches the first glyph but fails with the 2nd pair? I get a square with the skin tone similar to @guoyunhe picture, just the intended glyph is rendered differently(different font).

Chrome - eosrei original:

On Chrome viewing getemoji.com, these two emoji are also rendered as vertical rectangle pair outlines, assigning the font-family from eosrei did not reproduce the split graphic seen on that site.

Chrome - getemoji - No tone original:

Chrome - getemoji - Light tone original:

Setting the font-family to "Noto Color Emoji" fixes all the vertical rectangle pair glyph errors to show the proper emoji rendered for getemoji.com, on eosrei, it looks like @guoyunhe has shown above.

Chrome - getemoji - No Tone fixed:

Chrome - getemoji - Light tone fixed:

Chrome - eosrei fixed(kinda, the light tone is not composing with certain emoji like they do on getemoji):

Firefox

On Firefox however, the eosrei rendering issue @guoyunhe shows is not there and it's fixed completely by assigning the "Noto Color Emoji" font. Firefox is however rendering the finger glyphs with "DejaVu Sans", instead of "Noto Sans Symbols2" prior to changing the font.

I had gone into about:config for Firefox to swap the emoji font from "Mozilla Twemoji" that it ships with to "Noto Color Emoji"(prior to all this); So perhaps it's something to do with that, or each browsers fallback defaults?

Firefox - eosrei original (failed glyphs are being prioritized by DejaVu Sans - exact same for no tone emoji):

Firefox - eosrei fixed (with Noto Color Emoji enforced as font-family in CSS):

Firefox - getemoji - No tone original:

Firefox - getemoji - Light tone original:

Firefox - getemoji - Light tone fixed:

No tone was omitted for fixed version since it had no issues in Firefox on getemoji here. Not sure what's up with the weird spacing/gaps in Firefox after applying the font. Interestingly both of the problem emoji identified by @guoyunhe are preceded by the whitespace/gaps. Without the fix, alignment was visibly off(especially noticeable with emoji on the right side), if comparison of such helps:

Firefox - getemoji - No tone fixed:

[polarathene]

The spacing/layout issue with Firefox appears to be due to how certain glyphs are rendering as "default", as in if you view the html text content, or copy/paste the emoji to any other field in the OS(not just within the web browser), where the content would not use the "Noto Color Emoji" and thus present 2 or more characters/glyphs in the text field.

Probably the same reason the spaces between the emoji are so much smaller compared to Chrome when using "Noto Color Emoji" where a space appears to be a full emoji width wide.

So that's more of a bug in Firefox doing the layout before calculating the final combined glyph width I guess?

[polarathene]

Firefox bug reported

Appears my earlier assumption was wrong about being due to fontconfig messing with layout. It's either the FE0H(Variation Selector-16) or ZWJ codepoints messing with the width of space characters. Bit weird since it seems to affect getemoji.com , but not the eosrei site.

[polarathene]

It's due to how the emoji were formatted in the HTML element. getemoji used a new line for each, where eosrei has no new lines. eosrei actually has emoji seperated with spaces, so the firefox bug is inserting spaces of emoji width for some reason on getemoji(but even if you manually add the spaces into the html, the white-space: normal(default) property in CSS is collapsing those(it keeps a single space if there's two characters between them on the same line(in the html text, not rendered element).

[polarathene]

I've found time to setup a custom font-config to resolve my rendering inconsistency/priority for emoji on Linux. Just looked into this mentioned bug report to see if it renders correctly.

This report can be closed. It's not a bug with the font, the reason for the issue is related to the source code. See the unmaintained repo with affected line in HTML here.

☝️🏻 == &#x270C&#xFE0F&#x1F3FB vs ✌🏻 == &#x270C&#x1F3FB(verify yourself here, set to hexadecimal instead of decimal output). It's been input incorrectly with the invisible/zero-width codepoint VS15(FE0F), which should not be inbetween the two codepoints(while it renders as 2 separate glyphs, it is treated as a single character). This was a developer error/bug in that projects codebase, they needed to properly combine the two codepoints for the correct emoji/codepoint sequence.

There does appear to be a bug in Chrome with rendering the skintone emoji/modifier in text content if it's not preceded by an emoji earlier, or the first in the element. The font fallback does not appear to work otherwise, the modifier also binds itself to the preceding character(including a space) which makes it treated as two characters like described above. I assume because that's how it's intended to be used with other emoji for modifying? Firefox behaves in a similar way, it renders correctly but still has a similar issue as described with binding and text handling.

[guoyunhe]

https://unicode.org/Public/emoji/12.0/emoji-test.txt

It is the Unicode standard:

270C FE0F                                  ; fully-qualified     # ✌️ victory hand
270C                                       ; unqualified         # ✌ victory hand
270C 1F3FB                                 ; fully-qualified     # ✌🏻 victory hand: light skin tone
270C 1F3FC                                 ; fully-qualified     # ✌🏼 victory hand: medium-light skin tone
270C 1F3FD                                 ; fully-qualified     # ✌🏽 victory hand: medium skin tone
270C 1F3FE                                 ; fully-qualified     # ✌🏾 victory hand: medium-dark skin tone
270C 1F3FF                                 ; fully-qualified     # ✌🏿 victory hand: dark skin tone

[polarathene]

Yes, and when you render it with the codepoints like that, it works just fine with the "Noto Color Emoji" font:

Are you using Firefox? That has a bug I've linked you to earlier. The earlier eosrei site you linked to with a screenshot does not render a valid sequence, I explained that in my last post. It might not have rendered properly for you to make sense though, here you go:

The eosrei emoji site is incorrectly encoded as 270C FE0F 1F3FB, the VS16 should not be inbetween the two. How does it look on Chrome for you on getemoji.com or the unicode reference you linked?

It looks like you have DejaVu Sans taking priority for some of your glyphs(most of the victory hand emoji) in your screenshot. Your emoticons must be rendering in black/white then?

[dougfelt]

At the end of section 2.4 of TR51 it reads:

To have an effect on an emoji, an emoji modifier must immediately follow that base emoji character. Emoji presentation selectors are neither needed nor recommended for emoji characters when they are followed by emoji modifiers, and should not be used in newly generated emoji modifier sequences; the emoji modifier automatically implies the emoji presentation style. See ED-13. emoji modifier sequence. However, some older data may include defective emoji modifier sequences in which an emoji presentation selector does occur between the base emoji character and the emoji modifier; this is the only exception to the rule that an emoji modifier must immediately follow the character that it modifies. In this case the emoji presentation selector should be ignored.

Technically this sequence should be accepted by renderers, though it is invalid, because some legacy data might contain it.

[tomasdev]

The current version of the font includes these properly.