The EmojiOne 3.0 font was released, the embedded version needs updating. https://emojione.com/emoji/v3
Here to ni? Jonathan in to have comment.
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....)
Flags: needinfo?(jfkthame) → needinfo?(timdream)
Component: Graphics: Text → General
Product: Core → Firefox
Version: 54 Branch → Trunk
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!
Whiteboard: [good first bug]
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
Whiteboard: [good first bug]
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?).
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 firstname.lastname@example.org and we can get you set up with a license and access to the necessary assets.
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"
I started an internal conversation awhile ago. Will follow-up.
Version 3.1 was released last month.
Summary: Update EmojiOne font to 3.0 → Update EmojiOne font to 3.1
Forgot to add the 3.1 announcement: https://www.emojione.com/blog/welcome-emojione-version-31 The major change is Unicode 10 support.
AFAICS, licensing remains a blocker here. Tim, any update on that side of things?
(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.
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?
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
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.
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?
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....
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.
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 email@example.com so we can iron out the details.
Who is on the hook for this?
(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.
Flags: needinfo?(jfkthame) → needinfo?(gerv)
What if the font is downloaded later, as the OpenH264 and Widevine plugins? This could also be applied to Math fonts.
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.
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
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/
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.
Summary: Update EmojiOne font to 3.1 → Replace EmojiOne with a free emoji font
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 firstname.lastname@example.org 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!
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
Hi thinkrick, did you see Gerv's response above? It would be great to keep this conversation moving forward :)
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 :)
(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.
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
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.
Never mind, I figured it out about the same time as I posted that comment.
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
(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.
Assignee: nobody → smswessem
Status: NEW → ASSIGNED
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 <email@example.com>". If this is incorrect you should modify it (I have mine set to "Timothy Guan-tin Chien <firstname.lastname@example.org>".) 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!
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?
"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.
(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.
What are the changes made in the new patch? Do you need any help?
(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 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!
(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 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)
Attachment #8962851 - Flags: feedback+
Will there also be a fixed release on the github repo for the font, so others may use it?
(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 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.)
(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 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.)
Attachment #8963608 - Flags: review?(jfkthame) → review+
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.
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.
(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.
OK; then I'm not sure what's going wrong there, it would need some debugging effort...
Attachment #8963608 - Flags: review?(dolske) → review?(timdream)
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.
Attachment #8963608 - Flags: review?(timdream) → review+
(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...
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/2b389ab99839 Replace EmojiOne with Twemoji, r=jfkthame, timdream
You need to log in before you can comment on or make changes to this bug.