iamcal / emoji-data Goto Github PK

Hi,

Please publish latest version to npm. thanks.

Hey,
First of all, great project.

I've been working on a library to display panels of emojies using your data.
As for now, using this library as peer-dependency (because in the future I'll make another libraries like emoji-input and such) and don't won't to include \ pack your data twice.

Peer-dependencies to github pages is not usual, better take it to npm.
Please consider

Would be cool if you could add the age to the JSON data, i.e. in which unicode version the emoji was introduced (i.e. 🤑 was introduced with Unicode 8.0).

/cc @mroth @javan

This is a gemoji issue really, but only pull requests are accepted on that repo, not issues, and I wanted to see if anyone's looked into this.

♥️♣️♦️♠️

♥️♣️♦️♠️

^ Those changed in iOS7/Mavericks to not have the card background (new unified versions visible in Safari)

Any idea on the best way to regenerate the emoji images so that a pull request can be sent upstream?

There are several other images that got some tweaks, but can't think which ones right now.

Apple just added over 150 new emojis from the Unicode 8.0 standard in iOS 9.1 and El Capitan 10.11.1.

some of the entries in emoji.json have an empty array for the property 'variations' (probably expected behavior), others, for example EARTH GLOBE EUROPE-AFRICA omit the variations property entirely. Not quite sure what's causing this but it makes parsing the file very inconsistent. Ideally standardize on the empty array case for all entries so someone parsing JSON can assume the property will always be present.

Hi there,

I’m currently implementing some work based upon your emoji data set.

The data set here doesn’t appear to take into consideration variation selector requirements for certain code points. As far as the data here is concerned, U+00AE ® is an emoji just as much as U+00AE-U+FE0F ®️ is.

Despite a “variations” key existing for some emoji, with U+FE0F VARIATION SELECTOR-16 included, this being present does not accurately indicate a character’s default Emoji_Presentation value!

I’d suggest either that this data set should provide the Emoji_Presentation data, or the unified values should include the U+FE0F VARIATION SELECTOR-16 in cases where the character’s Emoji_Presentation is False.

I’ve worked around this limitation by making use of a regular expression which takes variation selectors into account correctly for matching, but this isn’t ideal, as it means my application ultimately has two sources of truth!

For your reference;

• Chart of emoji code points listed by their default presentation
• Unicode Technical Standard 51’s Presentation Style section

Thanks for your work on this invaluable data set! 💜

Is there a reason indexed spritesheets are not a part of the emoji-datasource package? If not, I'll be happy to create PR.

Minor point, but currently for values docomo, au, softbank, google a character that is not in the character set is represented with a blank string, e.g. "".

Similar to the text: field, would it make more sense to rather set this to null if not present? I believe most JSON parsing libraries will "do the right thing" with this then?

sheet_google_64.png => sheet_google_64_indexed_128colors.png for each 64-bit spritesheet.

Preferred settings in ImageAlpha are:

• Median Cut (pngquant)
• 128 colors
• not dithered
• not IE6-friendly

Emoji's should be safe code points only, alternatively generate in table on the fly from unified value trough Javascript as new column left of ascii.

Update emojione sprites to the emojione 2016 Q1 update that was recently made available.

The individual emoji assets in the folders like https://github.com/iamcal/emoji-data/tree/master/img-google-64 can be optimized ~15% on average by running them through ImageOptim locally (up to ~50% in some cases).

It would be great if these assets were optimized in the repo rather than having to run them as an extra step.

This is somewhat at odds with removing the gemoji dependency in #7 but gemoji now has a json file for the catalog names [1] that might be better to use in the build_names.php [2] script

[1] github/gemoji#47
[2] https://github.com/iamcal/emoji-data/blob/master/build/build_names.php

Emojione split off the graphics from the code with version 3, hence a new repository at https://github.com/Ranks/emojione-assets. Version 1 assets are is still available at https://github.com/Ranks/emojione-legacy and version 2 at https://github.com/Ranks/emojione/tree/2.2.7.

UMBRELLA (2602) and UMBRELLA WITH RAIN DROPS (2614) both have the short name "umbrella". The second should probably be "umbrella_with_rain_drops".

I see you have plans to check for duplicate short names in general, but I'm happy to make a PR for this if it is helpful.

we are manually patching some of these internally at slack - would be better to fix upstream

Thanks for your project!
During the upgrade my emoji library I've found a small bug:

{ char: '👪', name: 'family', x: 14, y: 20 }
{ char: '👨‍👩‍👦', name: 'man-woman-boy', x: 41, y: 9 }

These emojis are completely the same, and family already has man-woman-boy alias

This emoji-data, along with js-emoji is working great on the web.

• always store emojis in db in colon syntax: :smile:
• use js-emoji to render the emojis easily on any platform
• (on web) - if users enter unicode themselves via the mac emoji keyboard - use js-emoji to convert the unicode into colon syntax
• (on native ios app) When a user enters an emoji directly from an ios native application it needs to be translated into the colon syntax. There are a number of swift libraries that do this, but they all seem incomplete and do not seem to use the this emoji-data set. Are there any known swift or objective-c libraries that use this emoji-data set?

Thank you 🙏 😄

There might be emoji we don't have in the catalog, but have images for from one of the sources. Let's scan those to be sure.

The emoij for SATELLITE ANTENNA and SATELLITE both have the short_name satellite.

Emoji at codepoint 1f4e1 should be assigned the short_name satellite_antenna.
Emoji at codepoint 1f6f0 should remain satellite.

e.g. https://www.facebook.com/images/emoji.php/v5/z88/1/32/1f600.png

Twemoji has been updated to include unicode 9 emoji – is it possible to re-build and include that data now?

this one requires the U+FE0F selector, but it's missing

So I'm completely new to the emoji world and trying to get it all worked out :-) We're using this library but finding that we hit an issue where some unicode bytes were missing and thus the emojis weren't found.

For example:
\xF3\xBE\x93\xAC => Russian flag
\xF3\xBE\x93\xA6 => US flag

Hit the problem because they are used in this tweet that came through the app we're using this library in: https://twitter.com/restorationm/status/617365812769353729

I found the missing emoji listed in https://github.com/atilag/skia-b2g-sgs2/blob/master/emoji/gmojiraw.txt.

Is this something intended, just a one off that we have to deal with, or is there another suggestion?

For now, I simply customized my lists to include those unicode bytes aliased to the equivalents already in the library.

Thanks!!
Alan

I see there is work towards supporting Android Nougat's changes with the Noto Color Emoji under the yifanfwu-update_google_nougat branch. How can I help to get this work completed?

Issue #37 could have been avoided if we tested for that during build.

The images are currently quite heavy. How about adding some sort compression?

For instance the sheet_google_64.png has a total of 3.44MB. I've run this image through TinyPNG and the result is only 1.00MB. That's a save of 72%!

What do you think?

For example: 👩‍❤️‍💋‍👩 (couplekiss_woman_woman), 👨‍❤️‍💋‍👨 (couplekiss_man_man).

Hey!
I've seen you have released a new minor version 2.5.x, where you split the emojies to different npm packages.
This is a blessing BUT it's a breaking release, should have been a major update (3.0.0).

Updating my package to this solved the issue, though many people came complaining to me 😭

Just wondering if it would be possible for you to add in the category of the image as a field in the emoji_pretty.json

but 1F3C7 is exists
why? ios/osx dont have any skins for 1F3C7?

Missing 1f468-200d-1f469-200d-1f466.png in img-apple-160

Would be nice to add the iOS 10.2 emojis (missing the bacon emoji gg)

I think showman should be snowman and snowman should be snowman without snow.

http://blog.emojipedia.org/windows-10-emoji-changelog

This is in the standard (http://unicode.org/emoji/charts/full-emoji-list.html#23cf) but is missing from the json files.

FSF approved licenses: https://gnu.org/licenses/license-list.html#SoftwareLicenses
OSI approved licenses: http://opensource.org/licenses/alphabetical

Hello! I'm not sure if this is an issue with this repo or an issue with emoji in general or what the heck. I am comparing the emoji alias definitions here with gemoji's (https://github.com/github/gemoji/blob/master/db/emoji.json)

and some of them don't match? Eg

:thinking_face: in emoji-data vs :thinking: in gemoji. Or
:face_with_cowboy_hat: in emoji-data vs :cowboy_hat_face: in gemoji

This is causing some funny problems for us because we have an autocomplete on the front end but then parse it using gemoji on the back end.

Any ideas? Feel free to close as a wontfix as needed, I just was confused because I can't find anyone else complaining on the internet about emoji naming discrepancies, and I thought it odd there's not a canonical set of alias rules. (or maybe there are but I couldn't find any!)

(PS - prior to some of the newer emoji releases we didn't have this problem. Like all the classic emoji - :grinning: :grimacing: etc all have the same names on both gemoji and emoji-data)

The old php-emoji code did this, so we probably can

The Unicode standard itself #59 only covers codepoints and their attributes, e.g. Emoji and Emoji_Presentation. All kind of character sequences that shall result in a single emoji glyph rendering are defined in Unicode® Technical Report (soon: Standard) # 51 Unicode Emoji. This includes the following:

• presentations
  • applicable emoji followed by either Variation Selector 15 (text) or 16 (emoji)
• flags
  • an Emoji Flag Sequence is a valid pair of Regional Identifier Symbol Letters (RIS), according to CLDR's implementation of ISO 3166-1
  • an Emoji Tag Sequence for ISO 3166-2 code elements (soon)
  • an Emoji ZWJ Sequence (only Rainbow Flag currently)
• skin tones (Emoji Modifier Sequence)
  • applicable base followed by Fitzpatrick modifier
• genders and professions (Emoji ZWJ Sequence)
  • profession emoji base followed by gender symbol (Female = Venus or Male = Mars, possibly soon Neutral/Ambiguous/Androgynous = Mercury)
  • human emoji base (Man or Woman, possibly soon Adult) followed by profession symbol

Emoji 4.0 released on 22 November 2016 added several sequences that most implementations now support (including iOS since version 10.2 #69 released in December 2016): emoji-data.txt. It also switched to English CLDR short names (usually in lowercase or with initial caps) that may differ from the immutable character names in Unicode (usually in uppercase or with initial caps), e.g. red heart vs. HEAVY BLACK HEART for ❤️.

Emoji 5.0 will add more sequences around the same time Unicode 10.0 will be released, due in June 2017.

PR #72 changes the Unicode source files accordingly to support Emoji 3.0 and 4.0, but is probably not enough on its own.

There are a bunch more flag glyphs in the 10.10.3 apple font. Once #19 is done, we'll have unicode codepoints for the remaining flags (111 of them!). With those, we can take them into account when building the map, we they'll get included correctly.

The official unicode page http://unicode.org/emoji/charts/emoji-list.html has a list of keywords for each emoji. This is useful for search.

What would be the best way to go about getting those keywords?

Hello!

Just wondering if you would be able to publish this repository through bower. Or maybe you have a good reason why you haven't done that already. Any thoughts?

Thanks

Every other combination of man, woman, girl, and boy is included except :man-woman-girl-boy:

What's going on here?

This will allow me to easily ingest new versions of the apple font without having to manually calculate the glyph->name mapping. There are about 1500 currently, so this is essential.

The basics are easy (parsing sbix and cmap tables), but unwinding the ligatures will be pretty tough (morx table).

Hi. It would be great to see this project in npm registry.

Maybe add a tiny bit of padding between the icons in the pre generated 20 and 32 spritesheets (64 works fine pretty much everywhere)? ShoeBox and most other utilities can't single out each icon otherwise (selects blocks of icons upon selection/extraction).

Hey. Thanks for the useful package!

Do you have any idea how Apple's emojis are licensed? The results of my google searches don't paint a clear picture. I'm wondering if it's allowed to use them in an app (e.g. how Whatsapp provides the same emojis on Android and iOS).

Samsung Android devices have their own emoji set - we should include them too