On GitHub.com, people predominantly use `:octocat:` and `:shipit:`, but
other custom emoji not as much. These two most used custom emoji also
happen to be specific to the GitHub brand, so it makes more sense that
we add them as custom emoji in the app itself rather than shipping them
with the gemoji library.
This represented Apple's palette of characters before, but now has no
purpose since the `Emoji.all` list plus categories represents the
character palette recommendation from Unicode.
If a raw representation of emoji includes VARIATION SELECTOR 16, but a
browser would render it as a color emoji even without that character,
drop the VARIATION SELECTOR 16 from the raw representation.
As mentioned by @mislav in github/gemoji#116, too many aliases can be
tricky, but tags don’t need to be unique. Therefore, replace new aliases
with new tags for the recently changed 😄 and 🎉 emoji.
In the GitHub Reactions menu, there are six emoji: 👍, 👎, 😄, 🎉, 😕, and
❤️. However, two out of the six (😄 and 🎉) have descriptions (“Laugh”
and “Hooray”) that do not actually correspond to Gemoji aliases. Add new
aliases to those two Gemoji so that they directly correspond to the
GitHub Reactions.
I don't like that Bundler now makes Gemfile.lock change whenever I bump
up gemoji version. There aren't many dependencies, so a missing
Gemfile.lock won't slow down CI too much.
Some emoji have gendered variants, but their default rendering (when
they don't include a gender symbol) is using a specific gender for
historic reasons. Ensure that these emoji contain a representation with
explicit gender symbol in their `unicode_aliases`.
Example: ensures that "sleuth or spy" (1F575) is also found as:
1F575: sleuth or spy
FE0F: variation selector-16
200D: zero width joiner
2642: male sign
FE0F: variation selector-16
The use of the term "rage" is not the same semantically, though the Apple implementation of "pouting face" is essentially the "angry face" plus color red. However, other implementations have more "pouting"-like visages, and so use of "pout" would be helpful.
In the event that someone tries to copy the gemoji emoji's into their
project using the rake emoji task, if that person has braces ( or ) in
the path, the task will fail. Example of error:
sh: -c: line 0: syntax error near unexpected token `('
sh: -c: line 0: `mkdir -p /Users/gmiller/Dropbox (Personal)/projects/gavinmiller.io/public/images &&
cp -Rp /Users/gmiller/.rbenv/versions/2.0.0-p598/lib/ruby/gems/2.0.0/gems/gemoji-2.1.0/images/emoji
/Users/gmiller/Dropbox (Personal)/projects/gavinmiller.io/public/images'
By escaping the paths in the rake task, this problem no longer occurs.
In Rails 4.2 `#asset_path` has changed. Prior to Rails 4.2,
`#asset_path` would search all asset directories, and prepend the
appropriate asset type directory name to the result:
asset_path("emoji/unicode/<id>.png")
#=> "/images/emoji/unicode/<id>.png"
However, In Rails 4.2 `#asset_path` doesn't do that anymore, and assumes
that you've specified the correct folder. Since Emoji images are copied
to public/images/emoji/unicode, `#asset_path` would then generate the
wrong URL path:
asset_path("emoji/unicode/<id>.png")
#=> "/emoji/unicode/<id>.png"
Using `#image_path` fixes that, because that method looks specifically
for images/ folder, so it will find the Emoji images.
Commands used:
$ rake images:extract
$ imageOptim -a -d images/emoji/unicode/
This required both ImageOptim and ImageAlpha to be installed as OS X apps.
We now operate on a new set of assumptions:
- Characters with VARIATION_SELECTOR_15 shouldn't render as emoji, even
if OS X doesn't respect that currently. This removes explicit aliases
that include VARIATION_SELECTOR_15.
- VARIATION_SELECTOR_16 is optional for most characters to render as
emoji on OS X. For those that *don't* have it optional, we include
VARIATION_SELECTOR_16 in their raw representation in `emoji.json`.
Other characters list their form including VARIATION_SELECTOR_16
implicitly in `unicode_aliases`.
- For emoji that consist of 2 characters + variation selector, we assume
that the selector can come between the 2 characters or *after* them,
so `find_by_unicode` now supports both forms.
- The `db/aliases.html` script ensures that `emoji.json` only contains
characters that Safari on OS X actually renders as emojis.
Unless these characters are followed by VARIATION SELECTOR-16, which
indicates that the should be rendered as emoji, OS X renders these
characters using plain font glyphs.
Previously we assumed that the emoji list we get from
`Category-Emoji.json` (OS X emoji character picker) are all valid emoji,
but for some reason some plain Unicode characters are included in there
without being suffixed with VARIATION SELECTOR-16.
Even if the emoji contains it, the filename on disk doesn't have to.
This will reduce having to keep renaming PNGs on disk while we tweak the
emoji database in the future in regard to which are required to have
VARIATION_SELECTOR_16 and which are not.
Category-Emoji.json contains many code point sequences ending in U+FE0F
VARIATION SELECTOR-16. OS X renders some of these code point sequences
as color emoji even if you strip off VARIATION SELECTOR-16. (And in fact
it even renders some of them as color emoji if you replace VARIATION
SELECTOR-16 with VARIATION SELECTOR-15, even though that is explicitly
requesting a "text" variant of the character).
We used to assume that VARIATION SELECTOR-16 was optional for all emoji.
But this doesn't match OS X's behavior. This could cause problems, e.g.,
if you were to use the unicode_aliases property to detect Unicode emoji
and replace them with images for browsers that don't support emoji
natively.
The Ruby code no longer does anything special with VARIATION SELECTOR-16
other than to remove it from the description of each emoji. The new
db/aliases.html file can be used to determine which the correct Unicode
aliases for each emoji are. That page takes each emoji, generates a set
of variants using VARIATION SELECTOR-16 and VARIATION SELECTOR-15,
and renders each variant into a <canvas> element twice: once with a red
font color, and once with a green font color. If the variant renders the
same way, the OS is rendering the variant as a color emoji, and we add
it to the "unicodes" array for that emoji.
So the new process for generating db/emoji.json is:
1. rake db:dump > tmp
2. mv tmp db/emoji.json
3. open -a Safari db/aliases.html
4. Copy the resulting JSON from Safari
5. pbpaste > db/emoji.json
This ensures that unicode_aliases only contains those code point
sequences which actually render as color emoji on OS X.
This is a breaking API change.
You probably have code that looks like
if emoji = Emoji.find_by_alias($1) { nil }
that you can change to
if emoji = Emoji.find_by_alias($1)
It's more likely that someone will want to add a new emoji with a custom
image rather than a character that has a Unicode representation.
Also move the VARIATION_SELECTOR_16 logic outside of Emoji::Character
since it doesn't need to be concerned with it.
- Emoji.create(raw) => yields to block
- Emoji.edit_emoji(emoji) => yields to block
The block forms are so that the list of aliases & unicode_aliases is
re-indexed after the update.
Gemoji implementation depends on `codepoints` and test depend on some
more Ruby 1.9-only features, so don't pretend that the library will be
1.8 compatible anytime soon. Probably never.
This reverts commit 6a781b6474.
Instead of an unfriendly LocalJumpError, raise the Emoji::NotFound
exception with a helpful message if the block was not given.
If a fallback block was given, yield the value for which the lookup failed.
Previously, emoji name & unicode aliases were determined by following
symlinks among `images/emoji/*.png`. This led to nontrivial code for
resolving these aliases, made it tricky for contributors to add new
aliases and inspect existing ones, and didn't leave room for adding
metadata to emojis such as tags or descriptions from the Unicode spec.
Moreover, the aliases as symlinks led to duplication of image assets in
users' applications, with `hocho.png` and `knife.png` representing the
same emoji but being two separate images. Users were also unsure what to
do with `unicode/{HEX-NAME}.png` files, which would end up among their
images after running the `:emoji` task.
This change removes the symlinks support and creates the list of emojis
and their aliases in `emoji.json`. A single emoji is now represented with
an Emoji::Character instance, which has the `image_filename` method to
determine the path to the corresponding image instead of having to
construct it manually.
Contributions to this project are [released](https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license) to the public under the [project's open source license](LICENSE).
Some useful tools in development are:
```
script/bootstrap
```
Sets up the development environment. The prerequisites are:
* Ruby 1.9+
* Bundler
```
script/test
```
Runs the test suite.
```
script/console
```
Opens `irb` console with gemoji library preloded for experimentation.
```
script/release
```
For maintainers only: after the gemspec has been edited, this commits the
change, tags a release, and pushes it to both GitHub and RubyGems.org.
If you are just adding new emoji or making a small fix, only increment the patch level "1.0.x". If you need to rename a ton of emojis or making any other radical (but still mostly backwards compatible changes), bump the minor version "1.x.x".
### Make a release commit
To prepare the release commit, edit the [gemoji.gemspec](https://github.com/github/gemoji/blob/master/gemoji.gemspec) `version` value. Then make a single commit with the description as "Gemoji 1.x.x". Finally, tag the commit with `v1.x.x`.
Example commit https://github.com/github/gemoji/commit/v1.0.0
Emoji images and names. See the LICENSE for copyright information.
This library contains character information about native emojis.
Installation
------------
Add `gemoji` to you Gemfile.
Add `gemoji` to your Gemfile.
``` ruby
gem 'gemoji'
```
**Sync images**
Images can be copied to your public directory with `rake emoji` in your Rails app. This is the recommended approach since the images will be available at a consistent location. This works best with cached formatted user content generated by tools like [html-pipeline](https://github.com/jch/html-pipeline).
**Assets Precompiling**
If you must, you can manually add all the images to your asset load path.
``` ruby
# config/application.rb
config.assets.paths << Emoji.images_path
```
Then have them compiled to public on deploy.
``` ruby
# config/application.rb
config.assets.precompile << "emoji/*.png"
```
**WARNING** Since there are a ton of images, just adding the path may slow down other lookups if you aren't using it. Compiling all the emojis on deploy will add overhead to your deploy if even the images haven't changed. Theres just so many more superfluous files to iterate over. Also, the urls will be fingerprinted which many not be ideal for referencing from cached content.
Example Rails Helper
--------------------
This would allow emojifying content such as: `it's raining :cats: and :dogs:!`
This would allow emojifying content such as: `it's raining :cat:s and :dog:s!`
See the [Emoji cheat sheet](http://www.emoji-cheat-sheet.com) for more examples.
```ruby
module EmojiHelper
def emojify(content)
h(content).to_str.gsub(/:([a-z0-9\+\-_]+):/) do |match|
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
