1358240 - Replace EmojiOne with a free emoji font

Status: RESOLVED FIXED

(Firefox :: General, enhancement)

Description

[Alexandre Folle de Menezes]

The EmojiOne 3.0 font was released, the embedded version needs updating.

https://emojione.com/emoji/v3

Comment 1

[Vincent Liu[:vliu]]

Here to ni? Jonathan in to have comment.

Comment 2

[Jonathan Kew [:jfkthame]]

Forwarding ni? to :timdream -- can you look into this and see if the updated version works nicely for us? (There's always the possibility the conversion scripts will need some tweaking to handle it well....)

Comment 3

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I unfortunately don't have any cycles for this work. Anyone interested can look at 

https://github.com/mozilla/emojione-colr

and specifically

https://github.com/mozilla/emojione-colr/blob/master/CONTRIBUTE.md

to generate the new font file. Thanks!

Comment 4

[Tim Guan-tin Chien [:timdream] (please needinfo)]

After looking into it I realize EmojiOne does not offer SVG assets under a free license anymore since version 3.0.

CC'ing Casey who had commented here: https://bugzilla.mozilla.org/show_bug.cgi?id=1231701#c127

Comment 5

[nicolas m]

And even the free (as gratis) PNG version won’t be rightly licensed since it disallows commercial use and therefore isn’t free (as libre). Possible solutions:

* Get in touch with Ranks see if they are open to consider a licensing exception.
* Fork EmojiOne 2 to keep it up to date with the emoji specification.
* Wait for a third-party fork and switch to it.
* Switch to Twemoji.
* Switch to Noto Color Emoji.
* Revive Firefox OS Emoji and upgrade it (possibly at first by completing it using glyphs from another font).
* If Mozilla’s ability to put resources into that is limited, join forces with other free software projects or companies that may be interested in a free emoji set (Gnome? Canonical?).

Comment 6

[Casey]

Our v3 license structure has changed, however, we're very interested in striking a custom license so that our emojis may continue to be shipped with Firefox. Please reach out to us at [e-mail] and we can get you set up with a license and access to the necessary assets.

Comment 7

[Caspy7]

Can anyone confirm that they have contacted the EmojiOne folk through the support email Casey provided?

I'll note that according to https://www.mozilla.org/en-US/MPL/license-policy/, "You must consult the licensing team before importing third-party code which is not under the MPL or Apache 2.0"

Comment 8

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I started an internal conversation awhile ago. Will follow-up.

Comment 9

[Alexandre Folle de Menezes]

Version 3.1 was released last month.

Comment 10

[Alexandre Folle de Menezes]

Forgot to add the 3.1 announcement:
https://www.emojione.com/blog/welcome-emojione-version-31

The major change is Unicode 10 support.

Comment 11

[Jonathan Kew [:jfkthame]]

AFAICS, licensing remains a blocker here. Tim, any update on that side of things?

Comment 12

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Jonathan Kew (:jfkthame) from comment #11)
> AFAICS, licensing remains a blocker here. Tim, any update on that side of
> things?

It's unlikely we will be shipping something that isn't public licensed. Supporting Windows 7 users is still a worth cause but we will need to find other ways.

Comment 13

[Caspy7]

Well, dang.  This is disappointing. 

Last I recall, EmojiOne was the best option. It has one of the most comprehensive sets and continues to grow and be maintained.  Are there any other viable replacements at this point?

Comment 14

[(not currently active) Ted Mielczarek]

Per comment 5 the best available options are probably:
Twemoji: https://github.com/twitter/twemoji
* Frequent updates, supported by Twitter, used in the Twitter web app
* MIT licensed
* Scripts for generating SVGinOT TTFs: https://github.com/eosrei/twemoji-color-font

Noto: https://github.com/googlei18n/noto-emoji/
* Supported by Google, used in Android
* Graphics are Apache 2.0 licensed (prebuilt fonts are SIL Open Font licensed)
* Scripts and prebuilt fonts build CBDT/CBLC TTFs

Comment 15

[Jonathan Kew [:jfkthame]]

It would be interesting to see if we could adapt the workflow used to generate the EmojiOne Mozilla font (in COLR/CPAL format) to work with the graphics from Twemoji, as this format will generally be much more efficient (more compact, faster rendering) than SVGinOT.

Whether we can actually do such a conversion will depend on details of how the SVG graphics are constructed, as the conversion to COLR/CPAL layered OpenType is not able to handle anywhere near everything that SVG can contain.

Comment 16

[(not currently active) Ted Mielczarek]

Presumably this is just a matter of seeing whether the layerize.js script we currently use:
https://github.com/mozilla/emojione-colr/blob/master/layerize.js

can handle the SVG files from Twemoji?

Comment 17

[Jonathan Kew [:jfkthame]]

That would be the starting point, yes; then, depending what sort of failures/glitches show up, see whether they're readily fixable.

There's also the question of whether the fontforge SVG import (which converts SVG outlines to TrueType outlines, once layerize.js has split the glyphs into color layers) will cope with all the paths; it's not terribly robust, in my experience. Getting EmojiOne through there was not a trouble-free experience....

Comment 18

[Alexandre Folle de Menezes]

It seems there's now an official solution for Android:
https://developer.android.com/topic/libraries/support-library/preview/emoji-compat.html

With this API, devices with Android >= 4.4 will always have support for the latest Emoji.

I have opened a new bug 1391715 for this.

Comment 19

[thinkrick]

Hi everyone, this is the founder/CEO of EmojiOne.

We'd love to be able to continue supporting the Firefox web browser.  We were all thrilled that our version 2 icons were chosen! 
 Although our new version 3 standard icons are no longer open source, we're more than willing to waive our licensing fees and continue to support this project under terms that work for Mozilla.

Please contact us at [e-mail] so we can iron out the details. 

Comment 20

[Dave Townsend [:mossop]]

Who is on the hook for this?

Comment 21

[Jonathan Kew [:jfkthame]]

(In reply to Dave Townsend [:mossop] from comment #20)
> Who is on the hook for this?

It depends which direction we're going, I guess.

To actually update the EmojiOne font, as per bug title, we'd need a resolution of the licensing issue, since the EmojiOne project is no longer under a free-software license. Gerv, is this something you can look into? (See comments 5, 6, 19.) I'm assuming our concerns would be about freedom (to redistribute/modify/etc), rather than purely about licensing fees (which EmojiOne has generously offered to waive).

Otherwise, we could consider adopting a different emoji set; there are options out there (comments 5, 14, etc), but someone would need to spend the time to investigate and solve any technical issues involved. :timdream and I originally worked on the EmojiOne integration, but are both pretty busy (I believe) with other projects at the moment.

Comment 22

[Alexandre Folle de Menezes]

What if the font is downloaded later, as the OpenH264 and Widevine plugins?  This could also be applied to Math fonts.

Comment 23

[Jonathan Kew [:jfkthame]]

Yes, we could probably do that, at least from a technical point of view. Sounds like a question for Product as well as Licensing teams to consider.

The work being done to "bundle" a standard set of fonts for fingerprinting resistance (see bug 1336208) could provide the mechanism to make this work, if we conclude it is a route we want to pursue.

Comment 24

[Gervase Markham [:gerv]]

Yes, I'm afraid non-free licensing is definitely a show-stopper. In the case where there are clear free alternatives, it's not even a long conversation. Workarounds such as a later download have sort of been implemented in the past when our backs are against the wall for some crucial bit of function such as an H.264 decoder, but this isn't that.

Has a free fork of EmojiOne 2 emerged since we last discussed this further up the bug, which was 5 months ago?

If not, then we will need to jump ship to another free Emoji set.

Gerv

Comment 25

[colin]

There is the Emoji Two project, which is a fork of EmojiOne 2 under the same license. It's looking for contributions to the new emoji.

https://emojitwo.github.io/

Comment 26

[Alexandre Folle de Menezes]

Well, there seems to be two viable options:
- Emojitwo (CC-BY-4.0): the fork is too recent, there's currently not enough changes to warrant an upgrade.  But it should be the easiest transition;
- Twemoji (CC-BY-4.0): already supports Emoji 4 and 5, but should be harder to transition;

I am changing the title of this issue to reflect the font change.

Comment 27

[thinkrick]

Sorry for the delay as I've been going through a move, but I just wanted to jump back in and reiterate that EmojiOne is most definitely committed to supporting you guys with our 3.1 emoji set under very similar terms as the previous set, and without any fees.

What's the best way to get the exact licensing terms you guys would need to feel comfortable moving forward with our latest emoji font? We can draft up a custom license for Mozilla/Firefox that will never expire, and will be good for all future updates to our v3 series, which will cover the next several years at minimum.

If someone can email us at [e-mail] to discuss details, that'd be great. Or let me know who I can contact directly :) Thanks for your support in all that you do!

Comment 28

[Gervase Markham [:gerv]]

Hi thinkrick,

(In reply to thinkrick from comment #27)
> Sorry for the delay as I've been going through a move, but I just wanted to
> jump back in and reiterate that EmojiOne is most definitely committed to
> supporting you guys with our 3.1 emoji set under very similar terms as the
> previous set, and without any fees.

Unless "very similar terms" means an open source licence, then I'm afraid we are not going to be able to come to an agreement :-( Mozilla has a firm commitment to using only open source software in Firefox. And I'm fairly sure it wouldn't meet your new licensing goals to make it available that way, given that this is precisely what you switched away from.

If you make your stuff not open source, you can't really expect open source projects to keep using it :-)

Gerv

Comment 29

[Jared Wein [:jaws] (please needinfo? me)]

Hi thinkrick, did you see Gerv's response above? It would be great to keep this conversation moving forward :)

Comment 30

[thinkrick]

Ah, I see the distinction a little better now and why the current licensing structure (even with some major modifications) may not work for Mozilla's needs.

We have a bit of a fine line to walk as we're trying to serve a few different communities, some with very different requirements from a legal standpoint, all with a single product and licence (in this case, namely Mozilla and our offline/tangible product licensing for things like tshirt printing).

Is there any middle ground available anyone here can think of that may work for all parties involved? For the offline world, we aren't able to let people have open source type access to our larger images (or vector images) for printing as it would hurt some of our retail partners. On a similar note, we also can't have people using the name EmojiOne for any offline products, either.

What I'm wondering is if we can provide assistance with artwork and licensing for Mozilla's font needs that would ultimately end up a fully open source font set that we could help maintain with future artwork updates. If we can get you what your community needs while still avoiding any of the above legal issues on the retail/print side of things, we'd love to help however we can! Any thoughts or input are much appreciated :)

Comment 31

[Justin Dolske [:Dolske]]

(In reply to Gervase Markham [:gerv] from comment #28)

> If you make your stuff not open source, you can't really expect open source
> projects to keep using it :-)

I think this concisely distills down the issue.

I'd also note that Firefox's emoji support is basically being offered as a fallback for (legacy) operating systems that do not include emoji fonts OOTB. So in lieu of a simple upgrade path here, I think it's entirely adequate do nothing (i.e., continue to ship the existing EmojiOne font). It's not perfect (missing newer emojii), but it solves 90% of the problem (users having _no_ emoji) and this isn't an area I think we want to be spending a lot of time on.

Comment 32

[Gervase Markham [:gerv]]

thinkrick: I don't think it's really for us to formulate your corporate strategy here in this bug :-) You need to decide that with your own management and lawyers.

I would note that you can stop people using the EmojiOne name by using a trademark, so that part is not necessarily a problem. However, open source means "use for any purpose" so you would not be able to license your emoji (as SVG, at any rate) as open source and also prevent people using them to make t-shirts and other offline things.

Gerv

Comment 33

[smswessem]

I tried to make a Twemoji version, but this is what I got when I ran make:

$ make
node layerize.js twe-svg.zip overrides extras build Twemoji\ Mozilla
events.js:136
      throw er; // Unhandled 'error' event
      ^

TypeError: Cannot read property 'forEach' of undefined
    at /home/travis/build/TheEssemCraft/twemoji-colr/layerize.js:387:29
    at Array.forEach (<anonymous>)
    at addToPaths (/home/travis/build/TheEssemCraft/twemoji-colr/layerize.js:385:19)
    at /home/travis/build/TheEssemCraft/twemoji-colr/layerize.js:525:9
    at Parser.<anonymous> (/home/travis/build/TheEssemCraft/twemoji-colr/node_modules/xml2js/lib/parser.js:303:18)
    at Parser.emit (events.js:159:13)
    at SAXParser.onclosetag (/home/travis/build/TheEssemCraft/twemoji-colr/node_modules/xml2js/lib/parser.js:261:26)
    at emit (/home/travis/build/TheEssemCraft/twemoji-colr/node_modules/sax/lib/sax.js:615:33)
    at emitNode (/home/travis/build/TheEssemCraft/twemoji-colr/node_modules/sax/lib/sax.js:620:3)
    at closeTag (/home/travis/build/TheEssemCraft/twemoji-colr/node_modules/sax/lib/sax.js:861:5)
make: *** [build/codepoints.js] Error 1

Is this an error with the EmojiOne version as well? How would I fix this? Here's my fork: https://github.com/TheEssemCraft/twemoji-colr

Thanks in advance.

Comment 34

[smswessem]

Never mind, I figured it out about the same time as I posted that comment.

Comment 35

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Essem, do you want to take this bug? It should simply involve checking in this file into the Firefox source code and tweak the file name here and there. You can find the instance of file names by looking at the original commit. (bug 1231701)

https://github.com/mozilla/twemoji-colr/releases/tag/v0.3.1

Comment 36

[smswessem]

(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #35)
> Essem, do you want to take this bug? It should simply involve checking in
> this file into the Firefox source code and tweak the file name here and
> there. You can find the instance of file names by looking at the original
> commit. (bug 1231701)
> 
> https://github.com/mozilla/twemoji-colr/releases/tag/v0.3.1

Sure, I'm downloading the mozilla-central branch right now.

Comment 37

[smswessem]

Attachment: Replace EmojiOne with Twemoji

Comment 38

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Thank you for preparing the patch. I've done a "try push" for you, i.e. running all tests against your patch to detect problems (that can be detected through automated tests).

https://treeherder.mozilla.org/#/jobs?repo=try&revision=a66d66de85e1afc1ed7f911d67741ea4f78dd838

Please noted that you have set your hg client to denote the authorship to "smswessem <[e-mail]>". If this is incorrect you should modify it (I have mine set to "Timothy Guan-tin Chien <[e-mail]>".)

If Try detects no problems, the next thing you should do is to set your patch for review. Go to https://bugzilla.mozilla.org/attachment.cgi?id=8957382&action=edit and set the drop-down beside "review" to "?" and set the textbox appeared to "dolske,jfkthame".

Let me know if you have any questions!

Comment 39

[smswessem]

I looked on DXR to find more files relating to EmojiOne when I came across a folder called "obj-x86_64-pc-linux-gnu". However, the source code on my computer doesn't have this folder at all. What do I do about the files in that folder?

Comment 40

[Tim Guan-tin Chien [:timdream] (please needinfo)]

"obj-x86_64-pc-linux-gnu" contains generated files. They will only show up when you build the program on your machine. You don't need to modify them directly anyway.

Comment 41

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #38)
> Thank you for preparing the patch. I've done a "try push" for you, i.e.
> running all tests against your patch to detect problems (that can be
> detected through automated tests).
> 
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=a66d66de85e1afc1ed7f911d67741ea4f78dd838

The result looks pretty green excepts a few "oranges" which might be unrelated. Just to be on the safe side I am retriggering these tests. You may set the review flag when you feel your change contains no known issues and is ready for review.

Comment 42

[smswessem]

Attachment: Replace EmojiOne with Twemoji

Comment 43

[Tim Guan-tin Chien [:timdream] (please needinfo)]

What are the changes made in the new patch? Do you need any help?

Comment 44

[smswessem]

(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #43)
> What are the changes made in the new patch? Do you need any help?

I just edited some more EmojiOne-related files. It might result in better try results.

Comment 45

[Tim Guan-tin Chien [:timdream] (please needinfo)]

New try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=090371ae7b164a9344a997d6a56319eefd64d911

Comment 46

[Jonathan Kew [:jfkthame]]

Comment on attachment 8958093 [details] [diff] [review]
Replace EmojiOne with Twemoji

This looks great -- almost! In a little testing, I noticed one issue: lots of emoji sequences, such as family groups, don't work as expected. E.g. <1f468, 200d, 1f469, 200d, 1f467> (man, zwj, woman, zwj, girl) should form a single glyph.

Looking into the GSUB table in the font, the reason becomes apparent: where the ligature rule should match a single u200d glyph, it actually looks for a sequence of three of them.

I guess what's happening is that in the EmojiOne conversion process, we received glyphs with names such as 1f468-1f469-1f467.svg, and the conversion script therefore interpolated the expected ZWJ glyphs into the OpenType rules it generated for these ligatures.

But with Twemoji, the original glyph name already includes the ZWJ characters, as 1f468-200d-1f469-200d-1f467.svg; when the conversion script subsequently _adds_ ZWJ between each component parsed from the glyph name, we end up with the current problem.

So this should be a fairly simple fix in the layerize.js script: basically, remove the insertion of 200d at https://github.com/TheEssemCraft/twemoji-colr/blame/master/layerize.js#L625 (and update comments appropriately).

Please give that a shot, and then post an updated patch. Thanks!

Comment 47

[smswessem]

Attachment: Replace EmojiOne with Twemoji

Comment 48

[smswessem]

(In reply to Jonathan Kew (:jfkthame) from comment #46)
> Comment on attachment 8958093 [details] [diff] [review]
> Replace EmojiOne with Twemoji
> 
> This looks great -- almost! In a little testing, I noticed one issue: lots
> of emoji sequences, such as family groups, don't work as expected. E.g.
> <1f468, 200d, 1f469, 200d, 1f467> (man, zwj, woman, zwj, girl) should form a
> single glyph.
> 
> Looking into the GSUB table in the font, the reason becomes apparent: where
> the ligature rule should match a single u200d glyph, it actually looks for a
> sequence of three of them.
> 
> I guess what's happening is that in the EmojiOne conversion process, we
> received glyphs with names such as 1f468-1f469-1f467.svg, and the conversion
> script therefore interpolated the expected ZWJ glyphs into the OpenType
> rules it generated for these ligatures.
> 
> But with Twemoji, the original glyph name already includes the ZWJ
> characters, as 1f468-200d-1f469-200d-1f467.svg; when the conversion script
> subsequently _adds_ ZWJ between each component parsed from the glyph name,
> we end up with the current problem.
> 
> So this should be a fairly simple fix in the layerize.js script: basically,
> remove the insertion of 200d at
> https://github.com/TheEssemCraft/twemoji-colr/blame/master/layerize.js#L625
> (and update comments appropriately).
> 
> Please give that a shot, and then post an updated patch. Thanks!

I updated the patch to contain the fix. It turns out that the fix killed two birds with one stone; I was having a similar issue with the test page where many ZWJ sequences/Fitzpatrick-modified chars would fail the test, and it was fixed by that.

Comment 49

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 8962851 [details] [diff] [review]
Replace EmojiOne with Twemoji

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=5c0ea5688e6d1353882d2fc0cfa2be1e341761c5

I have verified that the review comment on duplicate ZWJs has been addressed (via tests and layer_info.json)

Comment 50

[Mark Straver]

Will there also be a fixed release on the github repo for the font, so others may use it?

Comment 51

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Mark Straver from comment #50)
> Will there also be a fixed release on the github repo for the font, so
> others may use it?

Certainly, but I prefer to wait for the font to be landed here before doing so.

Comment 52

[Jonathan Kew [:jfkthame]]

Comment on attachment 8962851 [details] [diff] [review]
Replace EmojiOne with Twemoji

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

Looking good! One minor issue I just noticed about the .ttf, filed as https://github.com/mozilla/twemoji-colr/issues/26. This should (I think) be a trivial fix.

(This was a bug in the old emojione version, too, but as we're touching things it would be nice to fix it.)

Comment 53

[smswessem]

(In reply to Jonathan Kew (:jfkthame) from comment #52)
> Comment on attachment 8962851 [details] [diff] [review]
> Replace EmojiOne with Twemoji
> 
> Review of attachment 8962851 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Looking good! One minor issue I just noticed about the .ttf, filed as
> https://github.com/mozilla/twemoji-colr/issues/26. This should (I think) be
> a trivial fix.
> 
> (This was a bug in the old emojione version, too, but as we're touching
> things it would be nice to fix it.)

Fixed with https://github.com/mozilla/twemoji-colr/pull/27, will update the patch.

Comment 54

[smswessem]

Attachment: Replace EmojiOne with Twemoji

Comment 55

[Jonathan Kew [:jfkthame]]

Comment on attachment 8963608 [details] [diff] [review]
Replace EmojiOne with Twemoji

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

LGTM. (I haven't attempted to review the designs of the individual glyphs from Twemoji; but it looks like the process of creating a color font from the original graphics for use in Firefox is working well.)

Comment 56

[smswessem]

Attachment: UNFlagIssue.PNG

I did notice a problem with the UN flag emoji; however, I don't know how to fix it. A screenshot of it has been attached.

Comment 57

[Jonathan Kew [:jfkthame]]

I wonder if there might be an issue with inadvertently unclosed paths in the artwork there. But that's only a guess from how the rendering looks, I haven't examined the SVG.

Comment 58

[smswessem]

(In reply to Jonathan Kew (:jfkthame) from comment #57)
> I wonder if there might be an issue with inadvertently unclosed paths in the
> artwork there. But that's only a guess from how the rendering looks, I
> haven't examined the SVG.

That's not it, since I checked the SVG and every path had a Z at the end, which means that they're all closed.

Comment 59

[Jonathan Kew [:jfkthame]]

OK; then I'm not sure what's going wrong there, it would need some debugging effort...

Comment 60

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 8963608 [details] [diff] [review]
Replace EmojiOne with Twemoji

I guess we will have to take the UN flag issue as a known issue. Please log an issue on GitHub on that.

I will land this via autoland for you.

Comment 61

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #60)
> I will land this via autoland for you.

Actually, I will push this to inbound instead...

Comment 62

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/2b389ab99839
Replace EmojiOne with Twemoji, r=jfkthame, timdream

Comment 63

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/2b389ab99839