Ensure Emoji characters are shown with Firefox Emoji in FxOS

RESOLVED FIXED

Status

RESOLVED FIXED
3 years ago
14 days ago

People

(Reporter: pivanov, Assigned: timdream)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 5 obsolete attachments)

Comment hidden (empty)
Created attachment 8663849 [details] [review]
[gaia] pivanov:bug-1206844 > mozilla-b2g:master
Comment on attachment 8663849 [details] [review]
[gaia] pivanov:bug-1206844 > mozilla-b2g:master

Hey :) can you r+ this one?
Attachment #8663849 - Flags: review?(azasypkin)
Hey Pavel,

Sorry, I'm on PTO today, but will take a look tomorrow.

In the meantime, I left one Emoji-font-as-CSS-variable question at Github :)

Thanks!
Just for the records, here is how to test this PR (per offline discussion with Pavel):

1) Apply PR from bug 993899 to add Emoji keyboard;
2) Apply PR from this bug;
3) Push changes to devices;
4) Go to Settings -> Keyboard and add Emojis keyboard;
5) Play with it in Messages app.
Comment on attachment 8663849 [details] [review]
[gaia] pivanov:bug-1206844 > mozilla-b2g:master

Everything looks good except for the following issues:

* We need ".support-emojis" for the subject field inside message node (when message with subject is displayed in Conversation view);

* We need ".support-emojis" for the subject displayed in Report view;

* If I try to enter numbers using default English keyboard into fields with ".support-emojis" - I see fancy emoji numbers instead of ordinary numbers :)
Attachment #8663849 - Flags: review?(azasypkin)
Comment on attachment 8663849 [details] [review]
[gaia] pivanov:bug-1206844 > mozilla-b2g:master

first two points are fixed now ... for the 3rd one Patryk will give us more info.
Flags: needinfo?(padamczyk)
Attachment #8663849 - Flags: review?(azasypkin)
Hey Oleg & Pavel,
I might have told Pavel the wrong thing.
So the fancy numbers should be put into the Symbols category within the emojis, they should be selected like all the other emojis.

If the user types a number using the standard keyboard, the number should be displayed using the Fira font.
Flags: needinfo?(padamczyk)
Hey guys,

I'm afraid that we can not fix this issue for now ... because the normal symbol "1" and the icon "1⃣" are with same Unicode "U+0031" and because we use plain symbols not wrapped for e.g. with <span/> we can not show the correct symbol/icon. I will try to find a fix but 90% I think that we can't do it now.

Patryk? any ideas?
Flags: needinfo?(padamczyk)
Just for the accuracy "1⃣" is "U+0031 U+20E3" :)
I think we should not force the emoji font and let the font backend correctly fallback on the emoji font if it can't find a character in the default sans-serif font.

Another possibility is to reverse the font-family value: first sans-serif, then the emoji font. Then the default sans-serif font will be used by default, and then the emoji font only if the glyph is not found in the default font. This way we'll control better that _this_ font should be used and not another emoji font.

But I'd prefer that we first try the 1st possibiltiy and see how this goes.
The problem is that there are default Unicode icons in normal font.


and Oleg: Yes :) "1⃣" is "U+0031 U+20E3" but we can't use it that way for now ...
Comment on attachment 8663849 [details] [review]
[gaia] pivanov:bug-1206844 > mozilla-b2g:master

Removing r? until we find the solution for numbers.
Attachment #8663849 - Flags: review?(azasypkin)
We remove the digits 0-9 and the hash for now and we will add them after v2.5. 
as Oleg mention already, you can test the patch for this bug like this:

1) Apply PR from bug 993899 to add Emoji keyboard;
2) Apply PR from this bug;
3) Push changes to devices;
4) Go to Settings -> Keyboard and add Emojis keyboard;
5) Play with it in Messages app.
Attachment #8663849 - Flags: review?(azasypkin)
Created attachment 8667959 [details]
2015-09-30-18-25-49.png

Looks good now, just few more things:

1) We need "support-emojis" for Report view as well (subject field) - I've left comment at Github;

2) Looks like we need to remove "©" sign from Emojis font as well in addition to numbers and hash;

3) And not sure if we should do something with "sending" state - when message is in sending state we change text color to "#bfbfbf" and reduce attachments opacity to "0.5", but it seems we can't change color of emoji font :)

Hey Morpheus, please look at the point 3 and attachment, do you think we should do something here or it's OK? 

Also I'm going to run raptor tomorrow to see if we have any perf/memory impact with the new font, so keeping r? for now.

Thanks!
Flags: needinfo?(mochen)
You mentioned "it seems we can't change color of emoji font", but can we apply opacity to the emoji font?
Since it's more like a visual issue, I also loop visual designer Fang to give idea for this bug.
Flags: needinfo?(fshih)
(In reply to Oleg Zasypkin [:azasypkin][⏰UTC+1] from comment #14)
> Also I'm going to run raptor tomorrow to see if we have any perf/memory
> impact with the new font, so keeping r? for now.

Performance numbers look sane.

(In reply to Morpheus Chen [:morpheus]  UX from comment #15)
> You mentioned "it seems we can't change color of emoji font", but can we
> apply opacity to the emoji font?

Yep, we can apply reduced opacity instead of color change.

So, let's wait for reply from Fang to know if we need to change anything here.

Thanks!

Comment 17

3 years ago
Created attachment 8668354 [details]
SMS_MMS_thread_emoji_sending.png

We can apply the same opacity "50%" like we apply to the media in this sending mode. I've also attached the mock up for this screen. Let me know it works for you, Thanks.
Flags: needinfo?(fshih)

Comment 18

3 years ago
Created attachment 8668355 [details]
MessagingThread_VisualSpec.003.png

For the reference, here is the spec we use for the sending part, thanks!
Thanks for Fang's high efficiency.
Flags: needinfo?(mochen)
Great, thanks Fang and Morpheus!

Pavel, could you please update "sending" state according to what Fang recommended?

I believe all message state styles are located in single file [1].

Thanks!

[1] https://github.com/mozilla-b2g/gaia/blob/ca8abff50e8a5aba18397e67f0db28465efd1b36/apps/sms/views/conversation/style/message.css
Thanks all :)
rebased and all needed changes are done
(In reply to Pavel Ivanov [:ivanovpavel][:pivanov] UX from comment #21)
> Thanks all :)
> rebased and all needed changes are done

Left two small comments at github, please ping me on IRC once you're ready and I think we'll have r+ today :)

Thanks!
Created attachment 8669092 [details]
shot from WebIDE
I am a bit confused. Are we going to do this on *every* UI w/ user data instead of setting the font priority in Gecko?

How is this blocks Emoji keyboard?
Flags: needinfo?(pivanov)
ni? Julien to give more thoughts on that :)

Thanks!
Flags: needinfo?(felash)
Comment on attachment 8663849 [details] [review]
[gaia] pivanov:bug-1206844 > mozilla-b2g:master

Looks good now :)

So if we decide (waiting for Pavel's and Julien's replies to the Tim's question) that this is the way to go - r=me for this PR.

Thanks!
Attachment #8663849 - Flags: review?(azasypkin) → review+
I don't have idea Tim. Maybe Johnathan can give use more info.
Flags: needinfo?(pivanov) → needinfo?(jfkthame)
Why do we believe this is needed? ISTM that we should only be putting the emoji font first in the font-family list for elements that are expected to contain ONLY (or at least PRIMARILY) emoji.

For general content such as SMS messages, the 'font-family' should be specified as 'sans-serif' (i.e. the font we want to use for textual content, which will map to Fira Sans on FxOS), and fallback should automatically find the emoji font for characters that aren't supported by the text font. Maybe -- if there could be other fonts present that also have some of the emoji characters -- it might be useful to specify

  font-family: sans-serif, "Firefox Emoji";

to ensure that our preferred emoji font is the first fallback. But I think it's wrong to put the emoji font first in the list, in general.
Flags: needinfo?(jfkthame)
Thanks for the info Jonathan.
In this case we will show icons like 
(huh this icon bug my comment.)

Thanks for the info Jonathan.
In this case we will show icons like U+1F310 with the Fira font not with Emoji font and if we want to show the Emoji icon we need to wrap the icon i.e. with span and set the font to it like font-family: "Firefox Emoji";
right?

Tim, Oleg any thoughts?
(In reply to Pavel Ivanov [:ivanovpavel][:pivanov] UX from comment #30)
> In this case we will show icons like U+1F310 with the Fira font not with
> Emoji font and if we want to show the Emoji icon we need to wrap the icon
> i.e. with span and set the font to it like font-family: "Firefox Emoji";
> right?

Right. There should be very few icons where this is an issue, I assume ... as Fira doesn't include the great mass of emoji codepoints. This will just apply to certain symbols where Fira has a b/w version.

So if we have, for example, a UI button that we want to display the "emoji-style" U+1F310 globe, then it's appropriate to apply an .emoji class with font-family just on that button.
(In reply to Jonathan Kew (:jfkthame) (PTO until Oct 12) from comment #31)
> (In reply to Pavel Ivanov [:ivanovpavel][:pivanov] UX from comment #30)
> > In this case we will show icons like U+1F310 with the Fira font not with
> > Emoji font and if we want to show the Emoji icon we need to wrap the icon
> > i.e. with span and set the font to it like font-family: "Firefox Emoji";
> > right?
> 
> Right. There should be very few icons where this is an issue, I assume ...
> as Fira doesn't include the great mass of emoji codepoints. This will just
> apply to certain symbols where Fira has a b/w version.
> 
> So if we have, for example, a UI button that we want to display the
> "emoji-style" U+1F310 globe, then it's appropriate to apply an .emoji class
> with font-family just on that button.

That's very error prone because we don't know how many b/w icons in Fira (we could inspect the font file, but our knowledge will quickly outdated when there is a new version of Fira gets pushed into the phone.). It is also a hassle to ask Message app to pick these characters out in a message just to wrap it with <span class="emoji"></span>.

The best case here would be enforce a emoji codepoint blacklist in Fira where it should never point a glyph to those code points. I don't know if it should be in the font itself (better) or enforce in Gecko (worse; but I thought that's how bug 1193481 was done and I was wrong after checking it).

Patryk should comment. He is already needinfo'd.
(In reply to Tim Guan-tin Chien [:timdream] (OOO Oct 9-18; please ni? to queue) from comment #32)
> The best case here would be enforce a emoji codepoint blacklist in Fira
> where it should never point a glyph to those code points. I don't know if it
> should be in the font itself (better) or enforce in Gecko (worse; but I
> thought that's how bug 1193481 was done and I was wrong after checking it).
> 

tl;dr this: create a Fira-no-emoji variant font file and use it along side with Firefox Emoji.
Flags: needinfo?(pivanov)
Summary: Adding Firefox Emoji font support → [Message] Prefer Firefox Emoji font over sans-serif for user contents
(In reply to Tim Guan-tin Chien [:timdream] (OOO Oct 9-18; please ni? to queue) from comment #32)
> (In reply to Jonathan Kew (:jfkthame) (PTO until Oct 12) from comment #31)
> > (In reply to Pavel Ivanov [:ivanovpavel][:pivanov] UX from comment #30)
> > > In this case we will show icons like U+1F310 with the Fira font not with
> > > Emoji font and if we want to show the Emoji icon we need to wrap the icon
> > > i.e. with span and set the font to it like font-family: "Firefox Emoji";
> > > right?
> > 
> > Right. There should be very few icons where this is an issue, I assume ...
> > as Fira doesn't include the great mass of emoji codepoints. This will just
> > apply to certain symbols where Fira has a b/w version.
> > 
> > So if we have, for example, a UI button that we want to display the
> > "emoji-style" U+1F310 globe, then it's appropriate to apply an .emoji class
> > with font-family just on that button.
> 
> That's very error prone because we don't know how many b/w icons in Fira (we
> could inspect the font file, but our knowledge will quickly outdated when
> there is a new version of Fira gets pushed into the phone.). It is also a
> hassle to ask Message app to pick these characters out in a message just to
> wrap it with <span class="emoji"></span>.
> 
> The best case here would be enforce a emoji codepoint blacklist in Fira
> where it should never point a glyph to those code points. I don't know if it
> should be in the font itself (better) or enforce in Gecko (worse; but I
> thought that's how bug 1193481 was done and I was wrong after checking it).

Yes, I'd agree that Fira should not include emoji characters. And then there's no problem with arbitrary message content, for example; if the user includes emoji, they'll fall back to the FxEmoji font, while the main text will remain in Fira as specified.

The potential problem here, I think, arises with characters that aren't clearly "emoji" but rather "symbols" that can reasonably be expected to appear in a "plain text" form in fonts such as Fira, but may also have a "colorized icon" or "emoji-style" rendering. I don't think we should expect an app such as Messages to magically recognize such characters within arbitrary text and apply "emoji styling" to them. It's only when they're deliberately used in richly-styled contexts (such as UI design) that we may want to explicitly specify FxEmoji for them.

(In reply to Tim Guan-tin Chien [:timdream] (OOO Oct 9-18; please ni? to queue) from comment #33)
> tl;dr this: create a Fira-no-emoji variant font file and use it along side
> with Firefox Emoji.

It would be unfortunate to maintain a second variant of Fira just for this. If there are specific characters that you think should always appear in "emoji style" but are currently getting rendered by Fira, we should probably just drop them from the Fira character set altogether as being inappropriate for inclusion in a TEXT font.
Do we know how the other OS' do it? They would be running into the same issue. I wouldn't want to maintain 2 versions of Fira, so there has to be another way? Maybe we can give certain apps priority? The keyboard for instance should only display Fira, and when the emoji keyboard is triggered, it would only display emojis. Else where in the UI Emojis should take priority, that way we shouldn't have conflicts.
Flags: needinfo?(padamczyk)
I'm happy because I essentially gave the same answer as Jonathan in my comment 10 ;) I think it's just easier to remove the symbols from Fira if it's possible.
Another possibility is to blacklist it in CSS ? Maybe using unicode-range ? What do you think Jonathan ?
Flags: needinfo?(felash)
(In reply to Patryk Adamczyk [:patryk] UX from comment #35)
> Do we know how the other OS' do it? 

Pretty similar to what we're proposing, I think.

Looking at OS X, it appears that they largely try to avoid overlap in character coverage between the Apple Color Emoji font and the normal text fonts on the system.

Where such overlap does occur (e.g. the smiley-face U+263A ☺ in the old Miscellaneous Symbols block of Unicode), the color-emoji glyph won't usually show up unless text is explicitly styled with Apple Color Emoji.

Certainly, there'll be some specific contexts (such as the emoji keyboard) where it's appropriate to set the emoji font as the primary style; but in most other cases I think the user's (or app designer's) chosen text font should be the default, and we should rely on fallback to find the emoji font when necessary. And there should be few (if any) cases where a character that users would normally expect to see in "emoji style" is present in the default text font.
(In reply to Julien Wajsberg [:julienw] (away Oct 1st, 2nd) from comment #36)
> I'm happy because I essentially gave the same answer as Jonathan in my
> comment 10 ;) I think it's just easier to remove the symbols from Fira if
> it's possible.

Can we get a list of specific symbols that are at issue here? It's not clear to me how extensive this issue really is... are there just a handful of codepoints where we're seeing Fira but wish to see Emoji instead? Dozens? Hundreds?

> Another possibility is to blacklist it in CSS ? Maybe using unicode-range ?
> What do you think Jonathan ?

To apply unicode-range, we'd have to explicitly load Fira using @font-face rules, rather than just referencing it in the system font list. This could be done with src:local(...) rules, which are pretty lightweight, but it's still some extra overhead (and a maintenance burden) that I think we shouldn't need to take on.
I think for now we have ~30 icons for unicode 6.0 (here are for unicode 8.0 https://en.wikipedia.org/wiki/Emoji#ref_U2700_as_of_Unicode_version)

Maybe Tim and Julien can give us more info how we can implement this.

Hope this helps.
Flags: needinfo?(pivanov)
But how many of those icons are present (in b/w form) in Fira? AFAICS, the Fira fonts support virtually nothing from the Unicode U+26xx Misc Symbols and U+27xx Dingbats blocks (which IMO is entirely appropriate, as Fira is a text font family). So if the content is styled with:

  font-family: sans-serif, "Firefox Emoji";

I'd expect them to render from the Emoji font as desired. Is that not working?
I'm not sure about Fira Icons.
and I test this one:

font-family: sans-serif, "Firefox Emoji";

and doesn't work
Hmm, that's sad. What specific character(s) are you testing, and what font does it end up using to display them? (I think you should be able to find this out by looking at the element using the DevTools Element Inspector and checking the Fonts tab.)
Maybe a simple hosted testcase could help, pavel.
1) Apply PR from bug 993899 to add Emoji keyboard;
2) Apply PR from this bug;
3) Push changes to devices;
4) Go to Settings -> Keyboard and add Emojis keyboard;
5) Go to Messages app -> New message and put from Emoji Keyboard symbol U+1F310 (http://www.fileformat.info/info/unicode/char/1f310/index.htm) from tab Nature (second tab).
6) Inspect element #messages-input in DevTools (Fonts Tab) I saw this:

==============================
ABC
Fira Sans system
Used as: "fira sans"

ABC
Firefox Emoji system
Used as: "firefox emoji"
==============================


If we don't have these Emoji icons in Fira I think everything will work fine. You can test with other icons.

Hope this helps.
I think this character is especially in Fira.
Yes, Fira Sans includes U+1F310; I guess that was done so that it could be used as a "switch keyboards" icon before we had the emoji font at all, probably. AFAICS it may be the only character affected in this way, or very close to the only one.

We could consider removing that character from Fira, I think; or we could just let it render as a "text-style" symbol when it occurs in content. After all, it's hardly a high-frequency "emoji", nor does it particularly need to be colorized in order to be recognizable. When users want a pretty representation of the earth, they'd be better served by U+1F30D/E/F. (Do we have those in Firefox Emoji?)

If we specifically want U+1F310 to be rendered in color _when it's used as an icon for language-switching on the keyboard_, that's a case where we can explicitly apply the emoji font style as part of the design of the keyboard app.
We could move this symbol to Keyboard-Symbols.ttf if it's made to be used in the keyboard.
Yes we have U+1F30D/E/F icons in Emojis.
In case this is useful, I made this page for you:

https://everlong.org/mozilla/test-emoji/

This make it possible to test how characters are rendered with/without the emoji font, and with different fallback order.

I don't know how to forbid the use of system fonts though, so in the first part, Firefox manages to find glyphs in different system fonts than Fira.
(In reply to Julien Wajsberg [:julienw] from comment #47)
> We could move this symbol to Keyboard-Symbols.ttf if it's made to be used in
> the keyboard.

Keyboard have moved away from using that icon for a long time. Even if there is a layout keep using the icon, Keyboard-Symbols.ttf does contain U+1F310.

(In reply to Pavel Ivanov [:ivanovpavel][:pivanov] UX from comment #44)
> 1) Apply PR from bug 993899 to add Emoji keyboard;
> 2) Apply PR from this bug;
> 3) Push changes to devices;
> 4) Go to Settings -> Keyboard and add Emojis keyboard;
> 5) Go to Messages app -> New message and put from Emoji Keyboard symbol
> U+1F310 (http://www.fileformat.info/info/unicode/char/1f310/index.htm) from
> tab Nature (second tab).
> 6) Inspect element #messages-input in DevTools (Fonts Tab) I saw this:
> 
> ==============================
> ABC
> Fira Sans system
> Used as: "fira sans"
> 
> ABC
> Firefox Emoji system
> Used as: "firefox emoji"
> ==============================
> 
> 
> If we don't have these Emoji icons in Fira I think everything will work
> fine. You can test with other icons.
> 
> Hope this helps.

Pavel, is U+1F310 the *only* symbol affacted? It should be because the keyboard app itself does not specify Firefox Emoji before Fira either in it's CSS. If so we should file another bug to remove it from Fira (and INVALID this one since it's not needed anymore).
Flags: needinfo?(pivanov)
(Assignee)

Comment 51

3 years ago
partly-obsolete
(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #50)
> Pavel, is U+1F310 the *only* symbol affacted? It should be because the
> keyboard app itself does not specify Firefox Emoji before Fira either in
> it's CSS. 

Here is my finding. My phone is built with both Noto Sans CJK, Fira Sans, and Droid Sans Fallback, visually inspect all Emoji on the keyboard layouts I can find a few overwritten than U+1F310. 

Here is the complete list (manually complied so I hope there isn't any mistake...):

Fira:

* U+1F310 (GLOBE WITH MERIDIANS)

Noto Sans CJK:

* U+2600 ("☀")
* U+2601 ("☁")
* U+2702 ("✂")
* U+26A0 ("⚠")
* U+2668 ("♨")
* U+1F197 (SQUARED OK)
* U+1F195 (SQUARED NEW)
* U+1F199 (SQUARED UP WITH EXCLAMATION MARK)
* U+1F192 (SQUARED COOL)
* U+1F193 (SQUARED FREE)
* U+1F196 (SQUARED NG)
* U+1F201 (SQUARED KATAKANA KOKO)

Droid Sans Fallback:

* U+2744 ("❄")
* U+2709 ("✉")
* U+2712 ("✒")
* U+270F ("✏")
* U+2708 ("✈")

So clearly this is a problem unsolvable by simply "removing U+1F310 from Fira" since the other two fonts are out of our control. 

I am more leaning toward black listing these code points in Gecko now after the finding, either in compile time or in a pref (too slow maybe?). Jonathan, what do you think?

Either way it is undesirable to put metadata of Firefox Emoji into Gecko but it seems to be the only way.
Flags: needinfo?(pivanov) → needinfo?(jfkthame)
Comment hidden (obsolete)
Comment hidden (obsolete)
Tim, aren't these fonts bypassed if we use `font-family: sans-serif, 'Firefox Emoji'` ? Could we make this the default on Firefox OS ?
With this rule, wouldn't the other fonts be used only if nothing is found in the default sans-serif font (aka Fira Sans) and 'Firefox Emoji' ?
(In reply to Julien Wajsberg [:julienw] from comment #54)
> Tim, aren't these fonts bypassed if we use `font-family: sans-serif,
> 'Firefox Emoji'` ? Could we make this the default on Firefox OS ?
> With this rule, wouldn't the other fonts be used only if nothing is found in
> the default sans-serif font (aka Fira Sans) and 'Firefox Emoji' ?

You are mostly right. Let me set my comments as obsolete...

However, I would prefer we not to employ any Gaia changes (i.e. not to use |font-family: sans-serif, 'Firefox Emoji'| in content CSS). Instead, we should amend the definition of sans-serif (and other generic font families) on FxOS.

Asides from (a) removing U+1F310 from Fira, looking at gfxAndroidPlatform::GetCommonFallbackFonts() [1] I can see that we do not (b) try to find U+2600-U+27BF in the Emoji font.

[1] https://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxAndroidPlatform.cpp#172

U+1F197 etc. (the SQUARED characters) evaluate to true in |!IS_IN_BMP(aCh) && (aCh >> 16 == 1)|, so the fact that I am seeing Noto Sans CJK probably means they are not in the Firefox Emoji font at first place. We should (c) either remove them from the Emoji layout or add them into the Emoji font. Pavel could you confirm the non-existence of these characters in Firefox Emoji, and tell us if we should just remove it from the keyboard?

If people agree with (a) and (b) and (c) we can just do it... :)
Flags: needinfo?(pivanov)
Comment hidden (obsolete)
Comment hidden (obsolete)
(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #55)
> U+1F197 etc. (the SQUARED characters) evaluate to true in |!IS_IN_BMP(aCh)
> && (aCh >> 16 == 1)|, so the fact that I am seeing Noto Sans CJK probably
> means they are not in the Firefox Emoji font at first place. We should (c)
> either remove them from the Emoji layout or add them into the Emoji font.
> Pavel could you confirm the non-existence of these characters in Firefox
> Emoji, and tell us if we should just remove it from the keyboard?

Never mind about (c): it's not needed -- the current behavior in [1] already ensure we find these characters in the Emoji font. I realized I have local font.name-list.*.* perf set for locating U+1F197 etc. in Noto Sans CJK first.

Sorry about that.
Flags: needinfo?(pivanov)
The reason why (b) is needed is probably because of this:

https://dxr.mozilla.org/mozilla-central/source/modules/libpref/init/all.js#3945

I am running the phone on zh-TW locale. I guess we should clear some font names here any rely on gfxAndroidPlatform::GetCommonFallbackFonts() more?
(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #52)
> Or, simply make Gecko search for characters in Emoji fonts *first* if the
> code point is between (and includes) U+2600 - U+27BF *and* |!IS_IN_BMP(aCh)
> && (aCh >> 16 == 1)| like bug 1193481.

For the 26xx and 27xx ranges, I think it's questionable whether emoji-by-default display is appropriate; these are symbols that have a relatively well-established tradition of existing in "text form" in standard fonts.

I notice that although the color emoji font on OS X includes a number of these characters, they are NOT used by default unless the emoji font is the only system font that supports them. So if I type U+2600 or U+2601 into an email or IM message, for example, I see the b/w "sun" or "cloud" symbol from a standard text font, even though a colorful emoji-style one exists in the Apple Color Emoji font.

But having said that, AFAIK using a font-family list that include both Fira and FxEmoji (in that order), as suggested above, should solve this if we do want these characters to render in "emoji style" by default.

If this is wanted "globally", we can presumably do it by including Firefox Emoji at the end of various font.name-list.*.* prefs for FxOS.
Flags: needinfo?(jfkthame)
I'll find a Gecko solution then, hopefully only changing the pref.
Assignee: pivanov → timdream
Status: NEW → ASSIGNED
Component: Gaia::SMS → Widget: Gonk
Product: Firefox OS → Core
Summary: [Message] Prefer Firefox Emoji font over sans-serif for user contents → Ensure Emoji characters are shown with Firefox Emoji in FxOS
Depends on: 1216399
Created attachment 8676019 [details]
bug1206844testcases.html

This is the test case I am using. There is an important detail being left out from the previous discussions -- for some code points like U+26xx and U+27xx, it must be rendered in Color Emoji only when there is a VS16 appended.

Browsing through Character Viewer on Mac OS I realized it always append an VS16 or VS15 for code points in U+26xx and U+27xx -- I construct the test case by follow that rule.

In comment 51, tests by looking at keyboard app should not be the desired effect -- we should update the Emoji layout definition instead and show & output VS16 when applicable.

The test here shows what I said in comment 51 indeed affects Emoji for some locales. Hopefully patch all.js can fix that.
Attachment #8663849 - Attachment is obsolete: true
Attachment #8667959 - Attachment is obsolete: true
Attachment #8668354 - Attachment is obsolete: true
Attachment #8668355 - Attachment is obsolete: true
Attachment #8669092 - Attachment is obsolete: true
Attachment #8676019 - Flags: feedback?(jfkthame)
Depends on: 1216409
With bug 1216399 and bug 1216409 I can now make sure everything on the keyboard is rendered with Firefox Emoji font, _in en-US locale_.

The remaining work to do would be display Emoji in general, i.e. this bug and the test case.
Created attachment 8676056 [details] [diff] [review]
bug1206844.patch

I assume there is no ref test involved so not pushing to Try here.

I can see Droid Sans Fallback is listed for Android but I don't have a build to fix it so I will leave it as-is.

I can verify with my test case that all characters in "with VS16 (Expects Color Emoji)" are shown in color Emoji in all font family in all languages tested. The one exception is the U+263A in monospace because of Fira Mono. I figured that should not be an issue?
Attachment #8676056 - Flags: review?(jfkthame)
Pavel,

There are color changes unrelated to Emoji should be checked in for Message app, even though I move this bug to a Gecko fix. Do you want to file another bug and check this in?

https://github.com/mozilla-b2g/gaia/pull/31952/files#diff-ae01103c2cb0db2aec91f5c2f674a6ed
Flags: needinfo?(pivanov)
Comment on attachment 8676056 [details] [diff] [review]
bug1206844.patch

Ouch, this is not a correct fix.

Removing Droid Sans Fallback from font.name.*.zh* does make Color Emoji render in Firefox Emoji, however it also makes CJK character render in MotoyaLMaru W3 mono (looking at "月" confirms that).
Attachment #8676056 - Flags: review?(jfkthame)
(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #66)
> Removing Droid Sans Fallback from font.name.*.zh* does make Color Emoji
> render in Firefox Emoji, however it also makes CJK character render in
> MotoyaLMaru W3 mono (looking at "月" confirms that).

s/CJK/zh-TW locale/, obviously.
Created attachment 8676119 [details] [diff] [review]
prepend-emoji.patch

This is another fruitless attempt which adds "Firefox Emoji" ahead of "Droid Sans Fallback". The color Emoji did come back but since "Firefox Emoji" contains the glyph of "月" it will always be rendered in color Emoji :'(.

Looks like there is no way to solve this problem simply with pref. I will start trying patch the code instead.
Why does Firefox Emoji contain 月? Surely the "emoji-style" glyph there should be encoded as U+1F237.

It looks like similar problems might occur with some other characters, too: 割合営指有満無申禁空.
(In reply to Jonathan Kew (:jfkthame) from comment #69)
> Why does Firefox Emoji contain 月? Surely the "emoji-style" glyph there
> should be encoded as U+1F237.
> 
> It looks like similar problems might occur with some other characters, too:
> 割合営指有満無申禁空.

I have no idea... I hope bug 1032671 mean nothing to patch here (based on my understanding written in bug 1216440 comment 4).
Still, I think these characters should be removed from Firefox Emoji. I think this applies to all the Kanji characters that are currently duplicates of the "squared" characters at U+1F2xx. There appear to be 11 of these altogether, AFAICS.

Pavel, I suspect this may mean the font-building process is being confused by the character names: e.g. U+1F237 is named "SQUARED CJK UNIFIED IDEOGRAPH-6708". Despite the presence of the string "unified ideograph-xxxx" in its name, this glyph should NOT be duplicated at the codepoint U+6708! Same applies to the others here.
(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #65)
> Pavel,
> 
> There are color changes unrelated to Emoji should be checked in for Message
> app, even though I move this bug to a Gecko fix. Do you want to file another
> bug and check this in?
> 
> https://github.com/mozilla-b2g/gaia/pull/31952/files#diff-
> ae01103c2cb0db2aec91f5c2f674a6ed

Thanks Tim :) bug 1216639 created
Flags: needinfo?(pivanov)
(In reply to Jonathan Kew (:jfkthame) from comment #71)
> Still, I think these characters should be removed from Firefox Emoji. I
> think this applies to all the Kanji characters that are currently duplicates
> of the "squared" characters at U+1F2xx. There appear to be 11 of these
> altogether, AFAICS.
> 
> Pavel, I suspect this may mean the font-building process is being confused
> by the character names: e.g. U+1F237 is named "SQUARED CJK UNIFIED
> IDEOGRAPH-6708". Despite the presence of the string "unified ideograph-xxxx"
> in its name, this glyph should NOT be duplicated at the codepoint U+6708!
> Same applies to the others here.

Hey Jonathan,
just want to be sure that I understand correctly. I need to leave these CJK Emojis U+1F2xx and need to remove all other CJK icons, right?
Flags: needinfo?(jfkthame)
You need to remove the 11 "squared" glyphs that are in the main CJK character block:

  U+5272
  U+5408
  U+55B6
  U+6307
  U+6708
  U+6709
  U+6E80
  U+7121
  U+7533
  U+7981
  U+7A7A

The copies of these in the U+1F2xx range are the correct place for them.

I think the "circled" glyphs at U+3297 and U+3299 are probably OK, as those are special circled forms anyway (and there are no corresponding U+1Fxxx codepoints, AFAIK).
Flags: needinfo?(jfkthame)
All changes are landed in Bug 1216672

Hope this one helps.

P.S. Have in mind that we need to remove/change some Emoji Icons in Bug 993899, but before this is there anything that we need or that we waiting for?
(In reply to Pavel Ivanov [:ivanovpavel][:pivanov] UX from comment #75)
> P.S. Have in mind that we need to remove/change some Emoji Icons in Bug
> 993899, but before this is there anything that we need or that we waiting
> for?

They might be encoded on the wrong codepoint just like what's pointing out on comment 71.

Assuming all symbols are listed in the patch on bug 993899, I am going to go through them now.

Since this bug only affacts CJK locale, we don't really need to block on this -- we are close to ship Emoji layout on 2.5 :).
(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #76)
> Assuming all symbols are listed in the patch on bug 993899, I am going to go
> through them now.

Updated in bug 993899 comment 74
There is nothing to work on in this bug once bug 1216399 and bug 1216409 are fixed. The problem with Droid Sans Fallback or Noto Sans CJK will likely be addressed in either bug 1216440 or bug 1032671, as told by Makoto-san over IRC.

I am therefore close this bug as fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Attachment #8676019 - Flags: feedback?(jfkthame)

Updated

14 days ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.