Javascript toShort: all emoji test refuses to pass because the new shortcode for Turkmenistan flag overrides the ™ sign shortcode.

Taking a look to the PHP code, same thing there.

Also, this can happen with other countries flags. I did a quick review and 🆑 : cl : also match Chile flag.

I see a reduction of 50 - 90% in size on the PNGs when I run them through pngout:

http://blog.codinghorror.com/getting-the-most-out-of-png/

Hello,

the hearts on the "smiling cat face with heart-shaped eyes" Emoji One Emoji are white, see:

But the hearts should be red, like in the "smiling face with heart-shaped eyes" Emoji One Emoji, see:

Could you please fix it?

Regards

New flags weren't added. Probably because no test were run for them, producing issue #51.

One space in front of ascii emoticons is removed when converting to image.

e.g. something like "I <3 you" will be replaced by "I:heart: you" instead of "I :heart: you"

Unicode character U+263A is described as a "white smiling face". I read that the white is not meant to be taken as the color of the face, but rather that the face is outlined as opposed to filled. The native example depicts the most basic of smiley faces, and probably the one most frequently used as just ":)".

However, Emoji One has turned this emoji into a blushing face looking extremely relaxed (similar to ☺️). Taking the "smiling face" code point and putting this strange expression on it unfortunately leaves the basic smiling face nowhere to be found, and as such often entirely unavailable (like here on github as well as on Discourse).

Check out this page for a comparison:

http://www.emoji.codes/family

To me the following look out of place: Emoji One, Apple, Twitter, Phantom. The others all look mostly right, except for Samsung which seems to have interpreted the "white" wrongly.

I don't know who started with the blushing relaxed face, but I really hope there is still a chance to correct this so that we may also have a basic smiling face.

It would be great to have a web font version of EmojiOne that maps the appropriate Unicode code points to the correct emoji. It could then be used along with unicode-range in CSS to automatically make emoji work even in Chrome/Opera which currently don’t natively render emoji on OS X.

This way, only CSS would be needed to support emoji – no substitution scripts etc.

CC @bramstein @ForbesLindesay

A meaningless text “禁割秘” is written in 🏮.
The word “居酒屋” (izakaya) may be written in izakaya lantern as you can find in Google Image Search: 居酒屋 提灯, but other famous emoji fonts adopt red lantern without text.

Hello,

the "taxi":

and "oncoming taxi":

Emoji One Emojis are orange.

It's hard to recognize them as taxis.

I think it would help a bit if they were yellow instead of orange (I don't know of any orange taxi).

They are yellow in most other Emoji sets as well.

Putting some kind of "TAXI" sign onto them might help as well, just saying.

Regards

Hello,

the Emoji One Emojis do not have a faint, narrow contrasting border to keep them visually distinct from a similarly colored background.

The latest Draft Unicode Technical Report 51:

http://www.unicode.org/reports/tr51/

recommends to give Emojis a faint, narrow contrasting border to keep the them visually distinct from a similarly colored background.

Please give the Emoji One Emojis a faint, narrow contrasting border to keep them visually distinct from a similarly colored background.

Regards

Hello,

the Emoji One faces are orange.

IMHO they would look better if they would be yellow.

Could you please make them yellow?

It would be much appreciated.

Regards

Hello,

the "person with folded hands" Emoji One Emoji:

is wearing pink clothes and has a burst of light around his hands.

But it should wear blue clothes and should not have a burst of light around is hands, just like other popular Emoji sets, see for example:

https://twitter.com/emojipedia/status/579000677831192576

Could you please fix it?

Regards

Hi Team,

I'm trying to use the Javascript method to get EmojiOne working, but I was wondering how I can set the image path in the Javascript. Right now I have something like this:

<script type="text/javascript">
    $(document).ready(function() {
        $(".emojione-convert").each(function() {
            var original = $(this).html();
            var converted = emojione.shortnameToImage(original);
            $(this).html(converted);
        });
    });
</script>

I have it working with PHP:

Emojione::$ascii = true;
Emojione::$imagePathPNG = '/images/emoji/';

But I need to get it working with Javascript because for whatever reason the software I am using doesn't play nice with PHP but works great with Javascript.

Thanks,

Hello,

the "speaker with cancellation stroke" Emoji One Emoji:

does have sound waves coming out of it.

But it probably shouldn't, since it's muted.

It doesn't have sound waves coming out of it in other Emoji sets as well, see for example:

🔇

Regards

Hello,

the "ticket" Emoji One Emoji:

is hard to recognize as a "ticket".

Maybe it would help if you would replace the random dark lines on the ticket with some actual text and also give it a perforation line like in most other Emoji sets, see for example:

🎫

Regards

👍 for 2944238.

Like I said in #23 it would be great if we have a better integration in other frameworks, so this is my plan to restructure the PHP conversion.

This plan is outdated! This is the new plan.

Moving to namespace Emojione

First I would recommend to move the class inside the namespace Emojione. This can be done now and asap to reduce the work for developers in future. All PHP demos must be changed to Emojione\Emojione.

Split the class

Then It would be easy to split the class into 3(+1) Parts:

1. Emojione\Ruleset This class implement RulesetInterface and is generated by the database. It should have a big notice on top not to modify the file.
2. Emojione\Config This class implements the ConfigInterface. It requires a RulesetInterface and has methods to extend and get the rules.
3. Emojione\Client This class does the main work. It requires a ConfigInterface and has all existing methods toShort(), shortnameToImage(), toImage($str), etc.

This would allow to build a client with fully customizable configuration:

// Default or custom ruleset
$ruleset = new Emojione\Ruleset;
$ruleset = new My\Own\Ruleset;

// Default or custom configuration ...
$config = new Emojione\Config($ruleset);
$config = new My\Own\Config($ruleset);
$config->useSprites(true);
// ... with extra shortcodes
$config->addShortcode(':youtube:', 'icon_youtube.png');

// client usage
$emojione = new Emojione\Client($config);
$emojione->toShort('Hello world! 😄');
// returns "Hello world! :smile:"

+1. Emojione\Emojione This is a static flyweight. It provides the simple PHP Conversion like the current Emolione.class.php but works with the client behind the scene. This will also be need for backward compatibility.

// behind the scene: inside Emojione\Emojione
public static toShort($str)
{
    $ruleset = new Ruleset;
    $config = new Config($ruleset);
    $client = new Client($config);

    return $client->toShort($str);
}

// usage
Emojione\Emojione::toShort('Hello world! 😄');
// returns "Hello world! :smile:"

Planning the Interfaces

First we need to know which parts of Emolione.class.php are generated by database.

Emojione\RulesetInterface

The generated parts will be the default ruleset in Emojione\Ruleset and will form Emojione\RulesetInterface. I assume this parameters:

• $ignoredRegexp
• $unicodeRegexp
• $shortcode_replace
• $ascii_replace
• $unicode_replace
• $asciiRegexp

Emojione\ConfigInterface

All other parameters will be set in Emojione\Config:

• protected $ascii = false; // convert ascii smileys?
• protected $unicodeAlt = true; // use the unicode char as the alt attribute (makes copy and pasting the resulting text better)
• protected $imageType = 'png';
• protected $sprites = false;
• protected $imagePathPNG = '//cdn.jsdelivr.net/emojione/assets/png/';
• protected $imagePathSVG = '//cdn.jsdelivr.net/emojione/assets/svg/';
• protected $imagePathSVGSprites = './../assets/sprites/emojione.sprites.svg';
• protected $unicode_replaceWith = false;
• protected $shortcodeRegexp = ':([-+\w]+):';

PNG sprite display in Firefox pales in comparison to Chrome. They will sometimes look okay, but then other times will look downright awful. Leading to weird distortions, and bizarrely inconsistent anti-aliasing, this seems to be most apparent when the computed width and height of the sprite isn't an exact pixel value:
(Firefox on the left, Chrome on the right )

This was improved (though really more of a trade-off) by adding
image-rendering: optimizeQuality;
After which they look more like this:

Which is a hell of a lot better, but still pretty bad in comparison to chrome. Lots of clipped sides, and I'd say this looks a little overly crisp with too many hard edges. Display in firefox is kind of all over the board, varying from looking pretty good to looking downright awful depending on the both the individual emoji, and the size its being displayed at.

I'm hoping to find out whether this just comes down to Firefox having a worse image rendering engine than Chrome, or if there's more that can be done to keep things looking half decent.

I've setup a quick codepen here, which i used to take the screenshots above.
The issue here seems to stem from the fact that these sprites are resizeable, and positioned/sized from a combination of percentage based background offsets, and background-size.

Our actual sprite files are located under /assets/sprites.

Hello,

Emoji One still does not support the skin tone modifier feature.

Could you please add the skin tone modifier feature to Emoji One?

Regards

Hello,

the Emoji One websites have some Emoji category icons (smiley icon / flower icon / bell icon / car icon / symbols icon) which are being used to toggle between the Emoji categories on the Emoji One websites.

Could you please add those icons to the Emoji One GitHub repository?

Regards

It is wired that the man with kanmuri crown wears pink dress and the woman with osuberakashi hairstyle wears green.
🎎 are dairi-bina of hina-ningyō and there are some pictures in Wikipedia

When using the ASCII conversion (on say shortcodes to images) the ascii codes, e.g. <3 are converted to ❤️. However, this only works if a space precedes the ascii smiley like so:

<p>text <3</p>

It doesn't work if there is no space and/or it follows a HTML bracket:

<p><3</p>

This remains as the ascii rather than an image.

This is a weird request. However consider html5's "desktop notifications" whereas they don't accept html. So "toImage" makes everything worse (the desktop notifications spec does not allow html). If I store the notification in the database using "toShort" then I have ":emoji:" when I send that to the desktop notification it's obviously still ":emoji:".

In chrome (at least) desktop notifications support UTF-8 and I get the encoding (from my mac) of the "mac" emojis, which lead me to believe if there was a function called "shortToUnicode" it would help in these corner cases.

Hello,

on the Emoji One homepage you are saying:

http://emojione.com/

[...] But wait, there's more! 😯 Within the coming months, we'll release the newest emoji additions (which unicode announced in June, around 250 in all) including the ever-adorable middle finger. [...]

But they are still missing.

Could you please add the new Unicode Emojis to Emoji One?

And is there already an ETA for this?

Regards

Hello,

could you please update the Emoji familiy tree over there:

http://emoji.codes/family

?

Things I noticed:

• Generally some Emojis are not being displayed, even though they should be there (:one:, :two:, :three:, :four: etc. are msissing from the Twitter Emojis for example)
• You still seem to be using an old version of the Google Emojis, even though there was an update to the Google Emojis, see: http://blog.emojipedia.org/android-50-emoji-changelog
• You still seem to be using an old version of the Apple Emojis, even though there was an update to the Apple Emojis, see: http://blog.emojipedia.org/apple-2015-emoji-changelog-ios-os-x

Could you please fix that?

Regards

Is it possible to change the converted images back to unicode or shortName. I am directly converting the text in an editable div to submit to a database. The problem is I would prefer to store the small shortName or unicode and still allow the user to manipulate and copy/paste the images already existing. Is there a function to convert the images back?

It would be nice to have some examples of usage in node js. For the life of me I can't get it to operate. When I try to utilize a function it says "object" does not have that method.

var emojione = require("emojione/package.json");

emojione.toImage("words and then characters");

Thinking about this perhaps I need to just:

var e = require("emojione/package.json");

emojione.toImage("words and then characters");

Which would let emojione be more "static". Thoughts?

There are 2 square (1:1) national flags currently in use, Switzerland’s and Vatican City’s. Emoji One forces all flags into a 16:11 ratio but doesn’t do this consistently. Switzerland’s flag is put on an off-white background while Vatican City’s is modified to fill the full space:

vs

For consistency either the Swiss flag needs to be changed to fill the complete space or the Vatican flag needs to be a square on an off-white background.

Alternatively Emoji One should support proper square (and other, in the case of Nepal especially) flags. It is problematic to overlay flags on an off-white background the way it is now done for Switzerland and Nepal because the user is unable to tell if the flag should be this way (white rectangle with 2 triangles on the hoist side?) or not (the white expresses transparency?).

Hi, we also provide cdn service for this lib here:
https://cdnjs.com/libraries/emojione

would you please add it in readme? thanks!

Unicode supports more than just the 10 flags. WhatsApp seems to have implemented more flags already.

Are you considering adding more regional indicators (flags)? Is there anyway the community could easily create these themselves, e.g. is there a style guide to follow to make them fit in with Emoji One?

As I understand from jsdelivr/jsdelivr/issues/1886, emojione is using the custom CDN offer from jsDelivr. I noticed that the image asset paths (e.g. http://cdn.jsdelivr.net/emojione/assets/png/1F479.png) are not versioned while the javascript lib is (e.g. http://cdn.jsdelivr.net/emojione/1.2.2/lib/js/emojione.min.js).

I can see 2 problems with having emojione's javascript lib versioned while the assets are not.

1. Stale cached image assets when there are emoji updates.
   For example, 1.2.2 (092b2a3) had 3 emoji updates. I noticed that the CDN copy just got updated. But browser clients may not necessarily fetch the updated asset due to cache-control. I had to do a hard-refresh myself to see the new icons.
2. Missing / stale image sprites when there are new emojis.
   When new emoji are added down the road (and this is expected to happen), it is possible that the javascript lib served from the CDN will be updated to contain references to new emojis but the assets will not have these additions. This can be mitigated by incorporating CDN updates into the release build process, but the problem will still exist for developers using sprites (e.g. http://cdn.jsdelivr.net/emojione/assets/sprites/emojione.sprites.png). The browser will very likely retain the stale cached sprite css/image copy, even as the javascript lib changes.

Overly aggressive / forced cache-busting isn't a good thing. I'm wondering if it's possible for the CDN to support an optional versioned path to the assets that developers can use if they want to implement cache-busting.

Example: http://cdn.jsdelivr.net/emojione/assets/1.2.2/sprites/emojione.sprites.png

With this, devs can selectively cache-bust by changing the required html/javascript/css link. Example:

/* Javascript Example */
emojione.imagePathPNG = '//cdn.jsdelivr.net/emojione/assets/1.2.2/png/';
emojione.imagePathSVG = '//cdn.jsdelivr.net/emojione/assets/1.2.2/svg/';

/* Sprite CSS link */
<link href="//cdn.jsdelivr.net/emojione/assets/1.2.2/sprites/emojione.sprites.css" rel="stylesheet" type="text/css" />

/* Sprite CSS override */
[class*=emojione-] { background-image:url("//cdn.jsdelivr.net/emojione/assets/1.2.2/sprites/emojione.sprites.png") !important; }

Enclosed CJK Ideographs listed below are rough.
🈯🈳🈵🈴🈲🉐🈹🈺🈶🈚🈷️🈸🉑㊙️㊗️
Particularly, 🈳, 🉐 and 🈹 are obviously wrong.

Hello,

the red hearts which are present in various Emoji One Emojis, such as the "smiling face with heart-shaped eyes" Emoji One Emoji for example:

all are RGB 209,56,82.

There is too much blue and green in it IMHO.

IMHO the red should be more pure and vibrant.

Could you please change that?

Regards

Hello,

the "face with medical mask" Emoji One Emoji lools sick due to it's green/gray skin color, see:

Other Emoji sets don't do that.

So, please change it's face color to the regular face color.

Regards

In the javascript version

emojione.mapShortToUnicode() is slow and creates tons useless of instances at each run. This is actually executed at every single call to public conversion api from utf8 to image (= very often in a single page app or a big page).
It would benefits greatly from memoization, the only drawback is the current api to add manual emoticon does not provide easy hook to invalid this memoization (no setters).

I had to monkeypatch my version of emojione to preserve decent execution timing:

emojione._mapShortToUnicode = emojione.mapShortToUnicode;
emojione.mapShortToUnicode = function() {
  if (!emojione.memMapShortToUnicode) {
    emojione.memMapShortToUnicode = emojione._mapShortToUnicode();
  }
  return emojione.memMapShortToUnicode;
};

PS: Regexp could also be precalculated instead of being generated every single execution but gain are much less visible in normal situation.

Instead of seeing a skull I see a shocked ghost with legs, its 90% the mouth

Hello,

when comparing the symbol Emojis in the following category:

http://emoji.codes/family?c=other

you will notice that pretty much all the Emoji One Emoji symbols in that category match the color of the symbols in the Apple Emoji set, except for some few which don't.

These are:

• All the zodiac sign Emojis (green and orange in Emoji One set vs. purple in Apple Emoji set)
• The "restroom" Emoji (gray in Emoji One set vs. blue in Apple Emoji set)
• The "top with upwards arrow above" Emoji (white/blue in Emoji One set vs. black in Apple Emoji set)

All the others pretty much seem to match though.

So, any chance you could make the rest match as well?

Regards

Not sure if this is a bug in your HTML or JS code, but I've noticed that your site (e.g. your demo page: http://www.emojione.com/demo) performs both PNG and SVG requests. Reload the page with browser's DevTools Network panel active to see for yourself.

Shouldn't only one type of images be requested?

The current SLEEPY FACE (U+1F62A) seems to have a tear sprouting from its eye, the blue drop is especially close in composition and colour to the one on the FACE WITH TEARS OF JOY (U+1F602):

vs

I think this should be revised.

First off this is awesome! I think these emoji's are 100x better. As an iOS developer, I do have a question with regards to installation. What would be the recommended way to get these working in a native app? Is there a font file that we can download (similar to how Symbola allows visibility for the new unicode 7.0 emoji through a .TFF file)? Again thanks for such an awesome project!

Starting from the commit 80d41dd a link to emojione.sprites.css.map was introduced into the emojione.sprites.css file but the file is missing.
This cause an error while debugging on chrome, which show in the console log:

GET https://[my_url]/emojione.sprites.css.map 404 (Not Found) 

I've been using Emoji One for a project page, and it seems to be working fine for the most part, except Unicode Alt attributes.

Judging from the documentation on unicodeAlt, Unicode should be the default for Alt attributes.

So I am perplexed as to why Emoji One seems to be only using shortnames on my project.

Here is the relevant code from my project (full project repo can be found here):

HTML

<h2>Input</h2>
    <pre><code class="language-javascript">&#x1F4BB;&#x26AB;&#x1F333;&#x1F313;&#x261D;&#x1F42C;&#x1F60A;&#x261D;&#x1F317;&#x1F607;</code></pre>
<h2>Result</h2>
    <pre><code class="language-javascript">console.log('&#128522;');</code></pre>

Javascript

    emojione.unicodeAlt = true;
    emojione.imageType = 'png';

    $('.title,.main,.page-footer').each(function() {
        var original = $(this).html();
        var converted = emojione.toImage(original);
        $(this).html(converted);
    });

Is this a bug of some sort, or am I doing something wrong?

This gray mark fails to catch its original sense.

U+1F4AE WHITE FLOWER 💮 is actually the outline of the seal of excellent (or brilliant homework, according to the Unicode Character Database.)
Seals of excellent are used mainly in Japanese elementary school. It is important that the color of seals is red, because red is the standard color of seals in Japan.
Seal (East Asia)

よくできました - Google Images

WHITE FLOWER in The code charts of Unicode has no captions.

The one in Apple Color Emoji shows that 大変よくできました taihen yoku dekimashita (very good; excellent.)

Now, you could find that the one in Noto Color Emoji has a different shape.

File:Emoji u1f4ae.svg
It is はなまる hanamaru, literally “flower circle”. This mark drawn by a pen is also used in elementary school and has the same mean as a seal of excellent.
はなまる - Google Images

Sometime is useful to test a string or retrieve informations about a possible match.
I suggest to export the RegExps used to detect the matches or a function like:

    ns.match = function(line, startIndex) {
        var asciiReg = new RegExp(asciiRegexp);
        var unicodeReg = new RegExp(unicodeRegexp);
        asciiReg.lastIndex = startIndex
        unicodeReg.lastIndex = startIndex
        return asciiReg.exec(line) || unicodeReg.exec(line)
    }

I can make a pull request with this

Hello,

the "ghost" Emoji One Emoji:

is blue with white eyes.

But it is white with dark eyes in the majority of the other Emoji sets, so it probably would be better if it would be white with dark eyes in the Emoji One set as well.

Regards

Hello,

the "metro" Emoji One Emoji:

looks like a sign of a metro instead of like an actual metro.

In other Emoji sets, including the Apple Emoji set, it looks more like an actual metro, see:

🚇

It would be nice if you could change that.

Regards

I'd love to see emojis for branch, merge, etc. Any plans in that regard?

Somebody mentioned this library and I've noticed you folks are XSS prone.

This is a very bad approach to html escape/unescape, explained here why that is deadly wrong: https://gist.github.com/WebReflection/df05641bd04954f6d366

Thanks for any update and Best Regards

Hello,

the "top with upwards arrow above" Emoji One Emoji:

actually does not have an upwards arrow.

Here is how it looks in other popular sets:

🔝

Could you please fix it?

Regards