Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace emoji with opensource versions #64

Closed
wants to merge 1 commit into from

Conversation

@paradox460
Copy link

commented Oct 16, 2014

As outlined in #61, the images from AppleColorEmoji are ©️ by Apple, and as such, their distribution is a violation of copyright law.

There is, however, a complete opensource emoji font, that actually includes 27 more emoji than the Apple emoji, within the unicode ranges of 1f1e6...20e3.

That font is Noto, which is developed by Google. It is also used in several of Google's products, such as Google+, Gmail, Hangouts, and Android. Yes, its the android Emoji font set.

Interestingly enough, the color emoji from Noto are available as both PNG and as SVG, as can be seen here. The SVG option is of particular interest, because it may allow for the replacement of images with inline SVG or at least SVG symbols.

Noto is licensed under Apache, which is compatible with the MIT license Gemoji uses.


For this PR, I just converted all the SVGs from Noto to PNGs at the appropriate size, renamed them, and overwrote the existing icons. I then deleted the surplus icons, wich have no equivalent in Apple color emoji.

Unfortunately, by doing it this way, I managed to break almost all the tests 😞. This means that this PR probably shouldn't be merged.

If there is interest in fixing gemoji to be fully opensource, a good solution would probably be:

  1. Replace the code that converts AppleColorEmoji to PNGs with a code that converts Noto SVGs to PNGs.
    • Imagemagick, when compiled with the proper SVG libraries, can do this out of the box, fairly quickly
  2. Rewrite the tests to make use of the new behavior.
    • Possibly use the latest Unicode Emoji reference, rather than one maintained by Apple

Switching, wholesale, to SVG, is a little more complicated, but is also an option.

Thoughts?

@djfpaagman

This comment has been minimized.

Copy link

commented Nov 7, 2014

Twitter has also open sourced their version of emoji. today. I think it is a good move to move to open source versions, or to at least give a choice (like Slack does, see this screenshot).

Coincidentally also found Emoji One through that setting just now.

@paradox460

This comment has been minimized.

Copy link
Author

commented Nov 7, 2014

It also appears Discourse, Jeff Atwood's forum system, is using either the
android/nota emoji (the ones I added) or a set very similar

On Fri, Nov 7, 2014, 2:42 AM Dennis Paagman notifications@github.com
wrote:

Twitter has also open sourced their version of emoji
https://github.com/twitter/twemoji. today. I think it is a good move to
move to open source versions, or to at least give a choice (like Slack
does, see this screenshot http://img.springe.st/kc5d549y49.png).

Coincidentally also found Emoji One http://emojione.com/ through that
setting just now.


Reply to this email directly or view it on GitHub
#64 (comment).

@mislav

This comment has been minimized.

Copy link
Member

commented Dec 12, 2014

It's great that there are so many alternatives to Apple's emoji today that can be freely used. Personally I only like Emoji One out of available ones, but other people might like different sets. This is why I think that the direction which we should be going with this library is removing all the images from it, and just shipping scripts (e.g. rake tasks) that help you install the emoji assets. The scripts can handle downloading, extracting, and consistently naming the assets, and allow you to pick from one of the open sets or even Apple emoji if you want to take the legal risk.

@paradox460

This comment has been minimized.

Copy link
Author

commented Dec 12, 2014

I think that's probably the best approach. I'd be happy to help with
pushing the gem in that direction, through whatever means I can.

On Fri, Dec 12, 2014, 12:25 AM Mislav Marohnić notifications@github.com
wrote:

It's great that there are so many alternatives to Apple's emoji today that
can be freely used. Personally I only like Emoji One out of available ones,
but other people might like different sets. This is why I think that the
direction which we should be going with this library is removing all the
images from it, and just shipping scripts (e.g. rake tasks) that help you
install the emoji assets. The scripts can handle downloading, extracting,
and consistently naming the assets, and allow you to pick from one of the
open sets or even Apple emoji if you want to take the legal risk.


Reply to this email directly or view it on GitHub
#64 (comment).

@djfpaagman

This comment has been minimized.

Copy link

commented Dec 15, 2014

I'm also up to help. I was thinking about the best way to implement the downloading of the emoji sets. We can use git to clone the relevant repo, copy the images and remove the clone. But this has quite some overhead (for example, twemoji has all the .ai assets in the git repo) and requires adding a git dependency or using system git (which will probably cause a lot of other headaches).

An alternative may be to set up separate repos that have the assets clearly cut and ready, so for example gemoji-twemoji, gemoji-apple, gemoji-noto etc. The advantage of this approach is that you only need to download the files you want. You will still need some sort of git dependency, but I think it makes it easier to do it manually as well.

What do you think?

@paradox460

This comment has been minimized.

Copy link
Author

commented Dec 15, 2014

Splitting the gem up into component gems is certainly simpler.

Alternatively we can use submodules, but thats fairly complex and brittle

On Mon, Dec 15, 2014, 5:18 AM Dennis Paagman notifications@github.com
wrote:

I'm also up to help. I was thinking about the best way to implement the
downloading of the emoji sets. We can use git to clone the relevant repo,
copy the images and remove the clone. But this has quite some overhead (for
example, twemoji https://github.com/twitter/twemoji has all the .ai
assets in the git repo) and requires adding a git dependency or using
system git (which will probably cause a lot of other headaches).

An alternative may be to set up separate repo's that have the assets
clearly cut and ready, so for example gemoji-twemoji, gemoji-apple,
gemoji-noto etc. The advantage of this approach is that you only need to
download the files you want. You will still need some sort of git
dependency, but I think it makes it easier to do it manually as well.


Reply to this email directly or view it on GitHub
#64 (comment).

@mislav

This comment has been minimized.

Copy link
Member

commented Dec 15, 2014

On Mon, Dec 15, 2014 at 5:18 AM, Dennis Paagman notifications@github.com
wrote:

An alternative may be to set up separate repo's that have the assets
clearly cut and ready

How about setting up our own tarballs that have the assets clearly cut, ran
through image-optim and ready? For sets whose license allows distribution,
of course. Apple emoji would still have to be extracted from font on OS X
using script.

@paradox460

This comment has been minimized.

Copy link
Author

commented Dec 15, 2014

Doesn’t even have to be tarballs. A bunch of github repos full of SVGs isn’t all that big.

Hell, even going up to 4x png isn’t that big

@mislav

This comment has been minimized.

Copy link
Member

commented Dec 15, 2014

On Mon, Dec 15, 2014 at 3:06 PM, Jeff Sandberg notifications@github.com
wrote:

Doesn’t even have to be tarballs. A bunch of github repos full of SVGs
isn’t all that big.

Sure, except that it makes no sense for something to be a git repo if it's
not going to be versioned and have history.

@paradox460

This comment has been minimized.

Copy link
Author

commented Dec 15, 2014

Well, the icon packages may be updated with revisions and future icons, as has happened with Google Noto recently (they change some icons to be race agnostic, changed the “hairy heart” to be a colored heart, and added a few missing emoji, such as flags). But even then, might just make sense to distribute binary blobs of the changes, as you said

@mislav

This comment has been minimized.

Copy link
Member

commented Dec 15, 2014

On Mon, Dec 15, 2014 at 3:26 PM, Jeff Sandberg notifications@github.com
wrote:

changed the “hairy heart” to be a colored heart

whew so glad that they did that! :)

@paradox460

This comment has been minimized.

Copy link
Author

commented Dec 15, 2014

Same here. Wonder why it was ever a hairy heart to begin with.

@mislav

This comment has been minimized.

Copy link
Member

commented Dec 15, 2014

Perhaps 1F49B YELLOW HEART was too ambiguous in the Unicode spec so the
designer decided to take some artistic liberties :D

@paradox460

This comment has been minimized.

Copy link
Author

commented Dec 15, 2014

Something else I just thought of. There is an eventual plan for the unicode emoji space to support combining characters, as a means of displaying different skin tones. So, where 👦 is white/yellow in most sets now, it would eventually be 2 characters, the emoji, and a modifier for race. That might be something interesting to have to support, although I suspect its several years down the road. Probably a case of premature optimization

@obskyr

This comment has been minimized.

Copy link

commented Apr 28, 2015

Whoops. That "several years down the road" turned into months, I guess...

@mislav

This comment has been minimized.

Copy link
Member

commented Apr 28, 2015

Just to let everyone know that I have plans to change this library sometime in May (when I return from vacation) to allow picking between different emoji sets. Support for Fitzpatrick modifiers for skin color may also be coming as a 2nd step. Note that none of the opensource sets currently support skin color modifiers.

The goal is that gemoji stops shipping with PNG images, and to offer scripts to download/extract an image set in a size and to a directory of your choice.

@mislav

This comment has been minimized.

Copy link
Member

commented Apr 28, 2015

Since we won't accept this PR, because it adds images, this feature is now tracked as #72. Thanks for the discussion!

@mislav mislav closed this Apr 28, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.