1363365 - emoji modifier are not properly displayed in Android

Status: NEW

(Core :: Layout: Text and Fonts, defect, P3)

Description

[Julien Wajsberg [:julienw]]

Attachment: testcase-unicode.html

STR:
1. Open the attached file.

Expected:
We should see 2 characters (see attachment, screenshot taken on Firefox 54 on Linux)

Actual:
On Android 6 we see 3 characters: 2 first characters are black squares, last character is correct. On Chrome on the same device, we see 3 characters as well: the 2 first characters are squared with a cross, last character is correct.

On Android 7 we see the 2 correct characters on Chrome but only 1 incorrect character in Firefox (see screenshot).

Comment 1

[Julien Wajsberg [:julienw]]

Attachment: Rendering in Firefox Desktop (Nightly) on Linux

Comment 2

[Julien Wajsberg [:julienw]]

Attachment: Android 7

Comment 3

[Julien Wajsberg [:julienw]]

Attachment: Android 6

Comment 4

[Jonathan Kew [:jfkthame]]

(In reply to Julien Wajsberg [:julienw] from comment #0)
> Created attachment 8865841 [details]
> testcase-unicode.html
> 
> STR:
> 1. Open the attached file.
> 
> Expected:
> We should see 2 characters (see attachment, screenshot taken on Firefox 54
> on Linux)

Not necessarily...

AFAICS, your test file contains the sequence

  U+1F937  SHRUG
  U+1F3FB  EMOJI MODIFIER FITZPATRICK TYPE-1-2
  U+200D   ZERO WIDTH JOINER
  U+2642   MALE SIGN
  U+FE0F   VARIATION SELECTOR-16

Here, the EMOJI MODIFIER requests a light skin tone for the shrugging character. The VS16 requests "emoji-style" rendering of the MALE SIGN. And joining SHRUG/LIGHT + MALE with a ZWJ turns the whole thing into #426 in the Recommended Emoji ZWJ Sequences, v5.0.[1]

So if adequate font and rendering support is present, this entire sequence should render a single glyph, "man shrugging: light skin tone".

[1] http://unicode.org/emoji/charts/emoji-zwj-sequences.html

> Actual:
> On Android 6 we see 3 characters: 2 first characters are black squares, last
> character is correct. On Chrome on the same device, we see 3 characters as
> well: the 2 first characters are squared with a cross, last character is
> correct.

The various black squares or crossed squares are simply missing-glyph "tofu", indicating that no font was found that supports the characters in question.

> On Android 7 we see the 2 correct characters on Chrome but only 1 incorrect
> character in Firefox (see screenshot).

AFAICS, the Firefox-on-Android7 rendering is actually the "most correct" here, and the Chrome version is a fallback due to failure to support the emoji zwj sequence.

Comment 5

[Julien Wajsberg [:julienw]]

Thanks, I updated the description of attachment 8865842 [details].

Is there anything we can do to make things better ?

FWIW I took the emoji from a Telegram discussion.

Comment 6

[Julien Wajsberg [:julienw]]

^ Fixed the attachment's encoding, now it should display as intended.

Comment 7

[Jonathan Kew [:jfkthame]]

(In reply to Julien Wajsberg [:julienw] from comment #5)
> Thanks, I updated the description of attachment 8865842 [details].
> 
> Is there anything we can do to make things better ?

Well, in theory we could ship an emoji font with Fennec that supports these things, instead of relying on the device's installed font. But a complete emoji font is rather a big thing, and we're trying to reduce rather than increase our package size.

(The rendering in Firefox on desktop Linux will presumably improve if/when we update the bundled EmojiOne font to a new release; that's currently under discussion in bug 1358240.)

Comment 8

[Julien Wajsberg [:julienw]]

Looking at http://emojipedia.org/unicode-8.0/ with my device I see that only the skin tone are missing. That's too bad :(

I don't even know if we can add new fonts to an Android device, so there is likely no point displaying a message to the user to try to improve things. Should we close this bug then ?

Comment 9

[Jonathan Kew [:jfkthame]]

Well, we do ship fonts for fennec to use as default serif and sans-serif faces, in preference to the device's own fonts (Droid or Roboto or whatever). They're not installed globally on the device, they're private to the browser.

We could do the same with the EmojiOne font if we're willing to take the size hit. It would be delivered post-installation via the DLC mechanism (as we already do for the text fonts), so it wouldn't be part of the basic APK, but would still contribute to our eventual installed footprint on the device.

The other question we'd face, if we decided to do that, would be which emoji font to prioritize in the case where Noto Color Emoji (or some other vendor-provided font) -is- preinstalled, so there are then two emoji fonts that could render any given symbol.