I find that none of the drawn emoticons I see ever really depict what I mean by :/ It's not a sad face as in that set. It's like "huh" or "what" or "ok", neither sad nor happy, it's puzzlement, filler, sometimes a "uhhh". Maybe that's just me though.
I think that conveys "bored" or "unimpressed" more than "puzzled". Funny how two dots and a line mean such subtly different things to different people.
I've been using "emoticons" for quite a long time (1980s) and to me :\ means basically what bellerocky described... you might be sad, or you might be happy, but basically you're just kind of confused.
In any case, there may be a generational component to this, or it might even be "regional", though the regions would be more about which forums, etc you hang out on rather than a geographical region.
Agreed. I have always read it as "meh" (closely related to "shrug" with asterisks), however I could agree with "what" as well. It's definitely not sad though.
- the art (PNG and SVG images) is released under CC-BY-SA 4.0. This means it's okay for commercial and non-commercial use, as long as you include attribution ("BY"). You can also modify the images and redistribute as long as you don't change the licensing terms ("Sharealike", or SA)
- the code (PHP and javascript) libraries is GPL v2.
That's just Apple being typically arrogant (and other font designers following them, sadly).
The way to write a flag in emoji is to combine the two letters of its country code; e.g. for the French flag you write REGIONAL INDICATOR F + REGIONAL INDICATOR R. The font then magically turns that two-character sequence into a single glyph.
An emoji font could include up to 676 (26*26) flags; I think WhatsApp has something like 45 flags already (on Android).
My understanding is that Apple just included the standard Japanese emoji set, to help sell iPhones in japan. For a long time they were even hidden on non-Japanese iPhones.
The standard Japanese emoji set is pretty randomly put together and I don't remember my old keitai having that many country flags.
Doesn't this also mean that using the code in any web app would put the entire app (or at least all of the frontend code) under the terms of GPL, too?
That's how I usually see the license explained. If so, that's a bit absurd for a small "polish" library like this, especially one that hopes to "[excite] a new emoji lifestyle and culture for the web".
I'm curious though: why is it necessary to store the emoji characters as :shortnames: in the DB instead of using the corresponding Unicode characters, and then convert them to image tags when rendering them to HTML[1]?
Couldn't the Unicode characters be rendered directly on the HTML and then the emojis shown using a custom font via @font-face? Firefox at least seems to support this using color SVG fonts[2].
I think that would be a better solution, as it would allow copy&pasting text that includes emojis. Doing so in the current Emoji One demo page copies the emojis short names instead of the Unicode symbols. And it may even let the native emojis take precedence over the Emoji One set doing (I think):
body {
/* Use sans-serif before Emoji One to allow rendering native emojis. */
font-family: 'Open Sans', sans-serif, 'Emoji One';
}
You can store just the unicode characters to the db if you wish, the conversion script can convert both unicode, shortnames, as well as ascii text :-) to the images/svgs.
Storing the :shortnames: was just our suggestion because we've found that many web stacks aren't setup to handle multi-byte/UTF-8 characters by from the get-go. Doing it this way is an easier over-all approach, but by all means feel free to take our tools and customize to your own needs.
@font-face would definitely be the ideal solution, and hopefully something we can implement once the browser support is there, but at the moment we're trying to go for the most universal approach.
> @font-face would definitely be the ideal solution, and hopefully something we can implement once the browser support is there, but at the moment we're trying to go for the most universal approach.
That's very reasonable.
I wonder if there would be any problem if, instead of generating image tags like:
This should be pretty safe i think, as it's only client side, and browsers play nice with Unicode.
That change allows the browser to copy, for example, the text "What's not to 😍 right?" from the Welcome page, instead of copying "What's not to heart_eyes right?" (tested on Firefox/Ubuntu).
The question is whether screen reader software deals well with the unicode emoji characters. I would lean towards the conservative assumption that it doesn't. Even Chrome/Mac still shows a missing character box rather the emoji.
(Also that sentence needs a comma. "What's not to heart_eyes, right?")
That'd be a great balance, and something we're going to look into. It does however, complicate the conversion script so as to not accidentally replace Unicode characters contained within the <img> tags, so it'd require a fair amount of testing.
I think these emojis are cute, but I'm not really sure this is a problem that really needs to be solved... Although I'd love a way to specify a set of emojis that I actually want to see on all my platforms. I dunno.
Hey, we actually aren't trying to create a new standard, that would be awful and not what we're trying to accomplish. We're closely following the emoji standard published by Unicode, which all of the other major emoji sets follow as well.
Most implementations of emoji on the web use Apple or Twitter's emoji sets, which are not open source and may put you at risk of copyright infringement. Native implementation is fairly great on mobile at the moment, however desktop is another story, often displayed as just black boxes(most notably in Google chrome).
It's basically the same problem as picking a type face. The style of type can support the sentiment of the text, or it can clash with it (sometimes intentionally), and so on. So designers end up picking type faces with intent. It's reasonable assume document authors/designers want the same level of control over the rendition of a "sad" code point. So you'll see a similar ecosystem of emoji fonts.
A bigger problem here is user control because the font stacks on all of the big platforms don't support "mixin" style font use well.
You can illustrate this with an example outside emoji, even: Imagine you're an English speaker occassionally reading documents mixing Latin and Hangul (Korean) alphabets, and the app you're reading the doc in lets you set a preferred font. Most likely that font will only contain Latin glyphs - so where do you get the Hangul from? All of the stacks do support glyph substitution to fetch them from a different font, but users usually have no easy control over what font that will be. On Linux and Windows it works by specifying aliases (i.e. font Y is an alias for font X, so when font X doesn't have a glyph, we go look in font Y instead), but you can only do it in config files and the registry, there's no GUI control (both Linux distros and Windows try to provide some reasonable default aliases) so the user effectively can't pick a font anymore.
The same problem happens with emoji - it's hard for users to pick their "emoji font".
The monkey's hands are incorrect. Monkeys are not wearing a suit, so the back of their hands are generally the same color as their "sleeves".
Also the emoji used to tell your story are confusing to me at least. I had to read a few times to determine that the gun was a placeholder for 'kill' and not 'shoot' or 'gun'. I have no idea of that trophy is a substitute for a word, or just giving emphasis to the text that follows it. Why is there a monkey after the end of the first paragraph? Does it imply blindness, willful ignorance, stupidity, or monkeys in general? Perhaps it means 'doh!'. And the text is just as hard to read all the way through. I have to backtrack multiple times through a sentence to figure out what the emoji is supposed to represent, since they can have a 'literal' meaning (just the text of the word, which in itself is not so easy to determine which text is accurate), an implied meaning, an 'object' meaning and an 'action' meaning among others.
They clearly had no choice re the see no evil emoticon, it would just be a brown blotch and unreadable if it was all the same color. Same for a lot of the black and white renders of it. And of course the ASCII for it is just white with an outline, (/_＼) , are you going to complain monkeys aren't white next?
This website is terrible at conveying what this project is about.
what a confusing and unhelpful faq:
* What is the main purpose behind Emoji One?
We were in the middle of starting a new web venture (and still are actually) that needed a full emoji set,…
* How do I install Emoji One on my device?
End users don’t have to do a thing! Emoji will continue to work on your mobile devices just as they always have…
I spent a good 10 minutes reading stuff and navigating pages tried the demo and fail to understand why a set of instant messaging icons is newsworthy in any way and it could be useful to anyone.
Also, boasting free culture and open source and deliberately forgetting linux in the comparison chart feels odd, plus the promotion of this brand new upcoming revolutionary porn site feels out of place here.
I may be pessimistic but I don't see this getting widespread adoption anytime soon which is must for this to be of any use. I wouldn't care as I have banned those stupid and colorful useless icons a long time ago and I still use the works everywhere ascii art ^^
Some of the FAQ questions are geared towards the general public, check out our github page for more detailed development info:
https://github.com/Ranks/emojione
Unicode has set a standard for all emoji sets to follow, but if you want to implement them on the web, native desktop display varies drastically depending on the users device, and in a lot of cases there is no support at all (Chrome on windows).
This is especially useful for sites that accept input from mobile devices, ensuring that any emoji inputted from a phone will display correctly on desktop. Twitter has something similar in place using their own proprietary emoji set.
We did forget to include Linux's variant in the homepage graphic, however it is included on our full comparison table (Symbola): http://www.emoji.codes/family
I find myself curious about their :woman::no_entry_sign::dress: project - namely, what's the revenue model for all this free porn? My first guess is basically "Patreon for nakeds" but they really don't say anything about it.
I'm looking for an emoji solution right now for our site, actually would love the device-native solution, not using this "standard" library for all of them. Perhaps this would be the right royalty-free fallback if the device does not have native support.
I'm actually looking for their "problem #2" - but using the native and polyfilling everywhere seems to be very difficult -- I don't see any good posts or libraries to help with this yet.
I don't see that the SDKs provide ways of pulling the emojis out in a categorized list to choose from, it seems to all be about the conversion. If want a list of just emoticons, how would I do that with your SDK?
One more sorting question, how do sort within the category like at http://emoji.codes/ where all the smiley faces are together / people are together / etc. It has a very neat order. I've tried sorting by the unicode value but that wasn't it.
I'm not sure I understand. Aren't most emoji included in Unicode? I mean, they're sort of black and white and poor, but they're there. What does this add other than a new library of graphics that needs to be supported and may or may not be better than the ones we see on iPhone or Android?
I guess some are missing from the Unicode set. But I'm not sure I like the art style on this one, so I wouldn't choose it either.
The "native" column shows what your device will show by default just using the unicode characters, and in chrome on windows (fairly high demographic) they almost entirely display as black boxes. Every device is going to interpret them differently.
We're aiming to provide a full color set that closely follows the unicode standards, translates well to Twitter, Apple, Microsoft etc's proprietary sets and is freely available and modifiable to anyone who wants to implement them into their web or mobile app.
Interesting how the poo icon is interpreted differently by different mobile developers. Looking at the iPhone, Android and Windows poos: Apple thinks poop is happy, Android thinks its smelly, and Windows thinks its purely utilitarian.
Well I'm glad someone is tackling the pressing issue of online emoticons... that's a load of MY mind.
I'm sorry for being so sarcastic, unless I'm missing the point, please downvote me.
