Unicode Emoji rendered incorrectly on Google Chrome

emoji

(Dean Taylor) #1

Can we get emoji characters converted to images on desktop browsers?

Users entering smilies and other items on the iOS devices cause squares to be displayed on desktop browsers.

#Steps to Reproduce

  1. iOS user posts containing the following characters 😍😍😍
  2. Windows 7 / Chrome user visits page to read post

#Expected
:heart_eyes::heart_eyes::heart_eyes:

#Actual
##Characters
:heart_eyes::heart_eyes::heart_eyes:
##Screen Grab


Auto-replace emoji like ☺ with Discourse codes
(Kevin) #2

Hey guys!

I came across this post and just wanted to mention that Emoji One has open source code available in our repo for doing exactly what you describe here. It’s completely up to you how, if, and when you implement it but I just thought I’d pass it along.

We’ve made big improvements to the replacement methods since launch as well, if that was a concern. I’d definitely encourage you to check it out and see if it’s something Discourse can implement. After all, those black squares is exactly what we’re trying to solve! :wink:

We also have a demo of an autocomplete script similar to what is used here, except it also matches aliases and keywords. The keyword matching makes finding the right emoji a heck of a lot easier.

Lastly, we’ve made a lot of improvements in the emoji art since launch so I hope you guys can pull down the new art too :grin:.

Sincerely,
Kevin P
Emoji One


(Jeff Atwood) #3

Good point; I updated to the latest EmojiOne images.

The way it works right now is this:

  • there is a folder of english symlinks, eg. smile.png
  • these symlinks point to the actual unicode filename in the /unicode/ folder that represents the unicode codepoint, e.g. 3c4f.png

We probably need to change this approach.


(Kevin) #4

emoji.json in our repo has a lot of great meta data you can use for your custom implementation.

Also curious… is there an advantage you see to: first, using descriptive file names instead of the unicode codepoint? And second, storing the images locally rather than hot-linking the latest on jsdelivr?


(Jeff Atwood) #5

What if the Discourse is a private instance inside a company with no access to the Internet?


(Kevin) #6

Ah, good point. Local emoji could be an option perhaps? But that may just complicate it.

Also, a Ruby on Rails port of our Emojione toolkit would be a great addition, if you decide to take things further! :wink:


#7

It’s not all desktop browsers on all desktop OSes, though.
I can see smilies with heart-shaped eyes on Firefox/Linux and IE11/Win8.1, for example.
Chrome however, seems to not be able to render emojis correctly at all, even if your OS has fonts that support them that get used by all other browsers.


(Jeff Atwood) #8

Agreed, this is kind of specific to Google Chrome and perhaps even Chrome/Windows.

:heart_eyes::heart_eyes::heart_eyes: ← renders fine on Firefox and IE11 for me, in Windows.

Apparently there is a Google Chrome plugin that’ll make it work, Chromoji:

https://chrome.google.com/webstore/detail/chromoji-emoji-for-google/cahedbegdkagmcjfolhdlechbkeaieki/related

It’s kind of a font issue since these are Unicode characters that need to exist in the current font – and were added in 2010:

In 2010, hundreds of emoji characters were encoded as part of the Unicode 6.0 specification. But getting characters added to the Unicode Standard is a long, drawn-out process. In addition to the original Japanese emoji characters, the Unicode additions included other new characters — such as country maps and European symbols.

But clearly it does if IE11 and Firefox can render it. And confusingly, emoji work fine in Google Chrome for Android…


(Sam Saffron) #9

I am fine with an admin site setting that enables a remap (tied to emoji plugin) it can also serve to “consistenify” all emojis. I do however feel it should be something people can opt of cause it is “magic”


(Dean Taylor) #10

@codinghorror thanks for looking into it…

Humm…
I’m not sure this is what I would call “fine”, they are perhaps “not as the author intended”. And appear poorly rendered, specifically unable to see that the eyes are hearts etc.

Here is the rendering results in Firefox 32.0.2:

And the same for IE11:

This displaying is better than just the square blocks.

Sure - if this was just a personal preference I might install the chrome extension (in short test appears to work).


(Jonah Aragon) #11

Those are rendering fine for me on Chrome 38 for Linux. Is it just Windows? I don’t see why it would be.


(OvermindDL1) #12

Works fine for me on Chrome 37 on linux. Probably just a windows problem.


#13

That renders for me on chrome on linux.

It could be down to which fonts are being used / installed. I’ve had a lot of problems with various unicode glyphs that render fine for me in Firefox but not in Chrome.


(Jeff Atwood) #14

Yes, it will work in Chrome for Linux (apparently) and Chrome for Android. But not Chrome for Mac or Windows.


(Dave McClure) #15

On my Nexus 5, Chrome for Android renders it weirdly until I do something like open the composer window…

Before and after composer window opened:


(Jeff Atwood) #16

That seems like a bug in Chrome/Android. Are you on beta or release?


(Dave McClure) #17

Release 37.0.2062.177


(Marco) #18

Guys you should check StackExchange from time to time.
:smiley:


(Sam Saffron) #19

I would like to add an option to the emoji plugin to do the mappings from unicode to emoji images.

I am a bit confused though at how you generate the mappings I need:

What is the magic I need to do to get from 1F235 (the name of the image on disk) to \uD83C\uDE35 ?


(Marco) #20

http://www.unicode.org/Public/7.0.0/ucd/UnicodeData.txt

?