enable use of variation selectors to disable/enable graphical Emoji representation

RESOLVED FIXED in mozilla35

Status

()

Core
Layout: Text
--
enhancement
RESOLVED FIXED
6 years ago
3 years ago

People

(Reporter: tomer, Assigned: jfkthame)

Tracking

unspecified
mozilla35
Points:
---
Bug Flags:
in-testsuite +
qe-verify -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(5 attachments)

(Reporter)

Description

6 years ago
Created attachment 597200 [details]
testcase

Unicode 6.0 which released on late 2010 added the Emoji blocks to the standard. Version 6.1 stated that it should be possible to enable/disable the representation. It doesn't stated what should be the default case when u+FE0E/u+FE0F is not exists right after the character. 

Currently we doesn't have any support to replace these characters with graphical/colorful equivalents, but as soon as this support will land, we will also need an option for the site to control how these characters should be painted in the browser.

Attached is a simple testcase I made after borrowing some code from the Unicode documentation which might allow an easy way to test it.


26FA FE0E 	TENT text style 	[⛺︎]
26FA FE0F 	TENT emoji style 	[⛺️]
26FD FE0E 	FUEL PUMP text style 	[⛽︎]
26FD FE0F 	FUEL PUMP emoji style 	[⛽️]
(Reporter)

Comment 1

6 years ago
Created attachment 597211 [details]
current result

Currently there is no any graphical replacement, which make both tests to show the same result. The question is – does the browser can actually distinguish between the character displayed on lines 1/3 and the character displayed on lines 2/4?

Comment 2

6 years ago
Egads, *what* is this doing in Unicode?!?  Anyways, those are variation selectors, I think we already have an outstanding bug for supporting those.  So once variation selectors are supported and display of color emoji is possible (which is *not* currently standardized, argh), I don't think there's any work to do here.
Summary: Usage of u+FE0E/u+FE0F to disable/enable graphical Emoji representation → enable use of variation selectors to disable/enable graphical Emoji representation
Bug 719286 is our prototype for SVG glyphs in OpenType fonts, with patches. That will make colored emoji possible. We'll support animation too.
(Assignee)

Comment 4

6 years ago
(In reply to John Daggett (:jtd) from comment #2)
> Egads, *what* is this doing in Unicode?!?  Anyways, those are variation
> selectors, I think we already have an outstanding bug for supporting those. 
> So once variation selectors are supported and display of color emoji is
> possible (which is *not* currently standardized, argh), I don't think
> there's any work to do here.

We do support variation selectors (see bug 569350), so that should Just Work (given appropriate fonts).

What we may want to consider - once we have a font with coloured/animated SVG emoji available - is some mechanism to let the user choose whether the "emoji style" or "text style" should be used by default (in the absence of an explicit variation selector to control the choice). I suspect not all users will _want_ to see all-singing-all-dancing emoji everywhere....
That seems unlikely to be worth doing.
(Reporter)

Comment 6

6 years ago
(In reply to Jonathan Kew (:jfkthame) from comment #4)
> I suspect not all
> users will _want_ to see all-singing-all-dancing emoji everywhere....

I agree, so this variation support won't be enough and we will have to get additional of the following preferences: 

• Disallow graphical Emoji – don't respect u+FE0F at all.
• Allow Emoji by request - If the next character is u+FE0F or any other mechanism (HTML/CSS?).
• Allow graphical Emoji by default – i.e., for cases without u+FE0E/u+FE0F characters or any other mechanism.
(Reporter)

Comment 7

6 years ago
Created attachment 597363 [details]
Screenshot from Mobile Safari

It looks like Mobile Safari doesn't support this well, either.
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #5)
> That seems unlikely to be worth doing.

To be clear: I can't possibly imagine that this is important enough to add pref UI for. Therefore, 99.9% of users wouldn't benefit from such a feature.

Just possibly it might make sense to add a font-variant CSS extension to control use of UVS or something like that (hopefully more generically useful than 'font-variant-emoji'!). Then Web applications or browser extensions could apply this control.
(Assignee)

Comment 9

3 years ago
Regarding CSS and/or prefs control of emoji appearance, this might be useful/appreciated, but it's a separate issue from respecting the Unicode variation sequences that are defined to select the "text" or "emoji" style of rendering. If the text contains bare emoji codepoints, such a mechanism might be used to choose a preferred rendering style. But if the text contains explicit variation selectors, we should (if possible) respect those.

We do support variation selectors, provided they're supported by the font being used (comments 2, 4). But we don't (currently) have a mechanism whereby the variation selector can affect the font selection process; if the page is using a font that includes *only* color or *only* b/w emoji glyphs, there's no "variant glyph" for the VS to select.

If/when we finish bug 543200, this would probably help, as any <emoji, VS> pair would be considered a cluster and so we'd look for a font that supports the cluster as a whole. However, bug 543200 is likely to be tricky; moreover, it may not fully address the specific issue of emoji, where it's quite possible that the fonts concerned do *not* explicitly support the variation sequences, yet it would be desirable for font selection to pick different fonts (e.g. Segoe UI Symbol vs Segoe UI Emoji, or Apple Symbols vs Apple Color Emoji) depending on the UVS that is present. This is particularly true for the "emoji-style" symbols that have been unified with other pre-existing Unicode symbols in blocks such as U+26xx.

However, I think we can do a lightweight fix here that should substantially improve the user experience on current versions of OS X, Windows and Android (where color emoji fonts are now standard), without the complexity and cost of bug 543200 in its full glory. Currently, gfxFontGroup::FindFontForChar is given the current character for which we're selecting a font, as well as the preceding character (so that it can recognize certain cases with joiners where we want to ensure continuity). What I propose is that we also pass the *next* character to FindFontForChar. It can then be forwarded to GetCommonFallbackFonts, in the case where we need to use fallback, and that method will be able to see if there's a U+FE0E/FE0F variation selector, and use it to decide whether the color-emoji font should be preferred to other potential fonts, or relegated to the end of the list.

This would address bug 1054780, for example, by preferring the standard monochrome symbol font for BMP symbol ranges *except* when the symbol is followed by U+FE0F, in which case we'd prefer the color emoji font; and it will improve the rendering of examples like http://xn-------tj3b5125au5ohf9bds16cx5aj4q.blogspot.ch/2014/09/ where the coffee cup at the end of the post title is supposed to be rendered in "emoji style" due to the presence of a variation selector.
(Assignee)

Comment 10

3 years ago
Created attachment 8496984 [details] [diff] [review]
Use emoji-style variation selector to help GetCommonFallbackFonts make an appropriate choice.
Attachment #8496984 - Flags: review?(roc)
(Assignee)

Updated

3 years ago
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
(Assignee)

Comment 11

3 years ago
Created attachment 8496989 [details] [diff] [review]
Reftests for emoji-style variation selectors.

Currently, only OS X 10.8 passes all the tests here on TBPL, as we don't have the necessary color emoji fonts installed on the other platforms; hence the fails-if annotations. We'll be able to cut those down as we modernize our test platforms and have color emoji fonts available more widely.
Attachment #8496989 - Flags: review?(roc)
(Assignee)

Comment 12

3 years ago
Comment on attachment 8496989 [details] [diff] [review]
Reftests for emoji-style variation selectors.

Review of attachment 8496989 [details] [diff] [review]:
-----------------------------------------------------------------

::: layout/reftests/text/reftest.list
@@ +180,5 @@
> +== emoji-03.html emoji-03-ref.html
> +# the next two will fail on OS X 10.6 and on Windows prior to 8.1 because no color emoji font is present,
> +# and also on Linux/Android/B2G platforms until we have color emoji fonts there
> +fails-if(OSX==10.6||/^Windows\x20NT\x20(5|6\.[0-2])/.test(http.oscpu)||gtkWidget||Android||B2G) != emoji-03.html emoji-03-notref.html
> +fails-if(OSX==10.6||/^Windows\x20NT\x20(5|6\.[0-2])/.test(http.oscpu)||gtkWidget||Android||B2G) == emoji-04.html emoji-04-ref.html

Oops....  s/gtkWidget/gtk2Widget/ in these annotations
https://hg.mozilla.org/mozilla-central/rev/65421ad99b13
https://hg.mozilla.org/mozilla-central/rev/b75cb73315c3
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
Flags: qe-verify-
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.