Hacker News new | past | comments | ask | show | jobs | submit login
Color Emoji in Windows 8.1 – The Future of Color Fonts? (opentype.info)
205 points by sanqui on July 8, 2014 | hide | past | web | favorite | 69 comments

Having both a color-unaware and color-aware versions can be really useful.

Printing for example would retain the meaning without a gray-scaled rendition losing the details to understand what the symbol might be. (This is just a guess, not an assertion that black-and-white symbols would be used in this context.)

From an accessibility standpoint, consider situations where high-contrast (and or size) is necessary, and it is perfectly legitimate to throw out or ignore the text and background colors for such users.

This solution seems to best satisfy comprehension needs for disabled users as well as printers--not that we need to print the bible translated to emoji any time soon.

I enjoyed this thorough breakdown of the different technologies. "Colorful typography on the web: get ready for multicolor fonts" http://www.pixelambacht.nl/2014/multicolor-fonts/

In particular, it expands on the details behind Adobe/Mozilla's SVG approach, as well as browser support.

I can't read this article without allowing Javascript.

That is true for about 50% of the links posted here these days. I usually just close the tab and read the comments on HN.

Note to site designers: something is terribly wrong if JS is needed to render the main textual content of your site.

Or just get with the program and allow JS. It's not going away, as flawed a language as it is.

Web browsers are an execution environment, no longer just document viewers.

> Web browsers are an execution environment, no longer just document viewers.

Indeed they are. But there is a real duality here. On HN, I see links to both applications and documents. Both of them happen to be HTTP links, since the web supports both.

I am mostly interested in the documents.

If you have a document to present, perhaps you should present it as a document, instead of requiring users to run your application to present your document?

If you want a responsive document that scales to all different screen sizes, modern touch-sensitive navigation for the content of this document, view-able on all the cornucopia of mobile and desktop browsers today then you need to use JS. Yes, maybe one in ten thousand web devs are the CSS master-wizards who can find a declarative way to do everything everywhere on any browser but it usually takes 10x the effort. Simpler to just use tested JS libraries

This seems pretty responsive to me:


>This site doesn't care if you're on an iMac or a motherfucking Tamagotchi.

That link is the best thing that's ever happened to the internet.

Why should the static content be dynamic? The responsive look can be a cherry on top of the static content.


No one but a tiny minority is even aware of the duality.

It's nice to be able to rely on JS being there, just like it's nice to rely on having the correct DOM constructed since HTML parsing has been standardised. There are things that are much easier to do this way.

It's not because I dislike JS the language that I disable it.

And, I do enable JS when I am on a familiar / trusted / interesting site. I definitely won't enable it on an unfamiliar / blank looking website.

But why should viewing a document require javascript execution?

Because CSS and HTML are woefully inadequate and JavaScript has to be used to produce many layouts.

What about Braille readers and stuff like that? How well do they support javascript?

Reportedly, accessible browsers do support JavaScript well enough. Modern ones are usually based on WebKit. They have to contend with the real world of websites (already) using JS to display content.

I think this is a great implementation. Embedding PNGs in to a font feels wrong - surely that doesn't scale up to large font sizes well? Or causes a blurry/pixellated downscaled image? Mixing bitmap with vector seems an odd engineering decision. Microsoft's approach is elegant in maintaining backwards compatibility and also enabling colored vector images on top.

The only downside seems to be a limited color palette, but I don't think that outweighs the benefits, and also encourages a clear and simple design.

These look really cool as does the technology, but I don't think I've ever used Emoji past a couple of ASCII smilies. My Android handset seems to have them but I don't use them and neither does anyone else I know.

Is this a cultural thing I'm missing?

If you're not female, a teenager, or from Japan, you're probably just missing the cultural context in which Emoji are used. I'm none of those, but I think Emoji are fun, and use them fairly regularly in casual sms conversations.

There is also much more history of their (easy) use on iOS than Android, which did not support them very well, if at all, until recent years.

Yeah, they're wildly popular with just about everyone I know 25 and under, especially on sites like Instagram. There's even been a music video created from them: http://www.youtube.com/watch?v=qmlJveN9IkI

Hmm. 40 year here who really likes using them. I find over instant messaging, which we use a lot at work, when you are just typing text a lot of the real meaning behind what you are saying is lost.

Compare the following mentioned during a code review:

Your code is crap Your code is crap :-)

The first is taken seriously, the second is more of a sarcastic joke. The meaning conveyed is even stronger when the picture is a comical and brightly coloured smiley face rather than an ascii smile.

I guess it's cultural, but I wouldn't IM "your code is crap" during a code review with or without an emoticon. If the code really was crap I'd be more constructive. If it wasn't crap I wouldn't say it was. Why wouldn't you just say what you mean?

Ok thanks. That's well under my age so I understand. Does it replace "TXT SPK" which I'm still too old to use and find terribly annoying?

(I'm sounding like a right grumpy old git here)

That sort of hyper-abbreviated writing has largely disappeared thanks to spell-check, predictive autocomplete, and so forth.

Emoji can certainly stand in for text, and I see plenty of comments and text messages that consist primarily of emoji. But just as often they will accompany text to add personality or mood the way ASCII smilies or textual kaomoji always have on bulletin boards.

>That sort of hyper-abbreviated writing has largely disappeared thanks to spell-check, predictive autocomplete, and so forth

Now that I think about it, you're completely write. It's been years since I've seen text-speak.

I think right autocompleted to write for you there.

Just think of Emoji as the ASCII smiley-faces- :) :( :D D: - version 3.0

Less of a replacement and more of a supplement.

I think so. They've become quite popular, I first noticed them from Apple users and wondered how they were creating neat little wing-dings type images in their posts, but now it seems everything has emoji options.

Recently getdavidhiggins posted a link on HN to http://emoj.li/ - an Emoji only chat. So it seems to be growing in popularity/ubiquity

They're used a bit differently to traditional emoticons - while emoticons are used to convey tone since text can be ambiguous, emojis tend to add 'flavour' to some text - things like icons of food, drinks, animals etc - so they generally have very little purpose, but make a message more fun.

I think it's a lot more useful if you have a layer of inderection on the input. I.e. what you type goes through autocomplete or an IME before being sent to the application you type into. It eases the need to switch to a different keyboard altogether just to input emoji, you just type "heart" and choose from the candidates.

That's a reason it is so heavily used in Japan, where they already have a two layer input system anyway. We might also have it easier and easier in ascii based languages as autocomplete like features develop and become ubiquitous.

On all the Japanese devices I've used, emoji input is a separate "keyboard" (or rather a different mode in the standard keyboard).

Some Japanese keyboards will sometimes suggest emoji during input conversion (the normal kana->kanji step), but it's a somewhat haphazard way of inputting them, and it's often easier just use the dedicated emoji input. The reason seems fairly clear to me: many emoji encode nuances that don't map easily to single words or small compounds in a way that's easy for a user to predict...

[My old non-smart phone would suggest some emoji during input conversion (e.g. if you convert "ねこ", it would suggest "🐱" and "(=^ェ^=)" as well as "猫"), but my current (Japanese) Android phone doesn't seem to do any of that at all (using the vendor Japanese keyboard); to input emoji you need to use the emoji input... :]

There is a separate emoji panel, but in my experience you tend to remember the name of the emoji used the most, and in 10-key mode it's pretty fast to type a 2 or 3 kana word.

About the android phones, I was a bit surprised by the low quality of Japanese support. But I didn't try the ATOK keyboard nor the input available on Sony phones for instance, only the Google IME. To Apple's credit, they've been doing IME on the mac for long enough to have a very good integration of the emoji in the system dictionary.

But really, my point was not only on the colourful emoji, but more on the fact that characters like ↑,♡,◎,△ are just unusable on a daily basis on a US/european computer, but are super easily summoned on a system with an IME. And Japanese people have been using these kind of pictograms in their communication for decades, the emoji used on the phones being just an advanced kind of the same thing. I think that would be the main cultural difference regarding to emoji.

The Japanese android vendor keyboards do seem to be generally much more polished than google's effort, although the latter is ok for basic Japanese input.

The main issue with conversion-based emoji seems to be discoverability.... Besides those reflecting basic concepts, there are tons of odd or intricate emoji that you'd never even imagine existed unless you saw them first; even once you know they exist, figuring out what input maps to them is at best a crap shoot (I've never found any way of getting the input system to tell you)....

About discoverability, when you start being a heavy user, the next step is to have custom entries in the user dictionary. It's almost mandatory for 2chan style smileys[0] with 7 or 8 characters in a row, and it also helps for obscure characters, emoji or not (there was a time "girl moji"[1] was a thing, with every letter splitted into 2 or 3 parts. I can't imagine that thing working without having all the letters in a user dictionary).

[0] http://matsucon.net/material/dic/kao01.html [1] http://plaza.rakuten.co.jp/love2kaomoji/5007/

I personally find Google's offering nearly unusable as someone who primarily types Japanese via romaji. The vendors do a much better job but I found the fastest way for me was Swype. Emoji support is basically non existent though

The Apple iOS and OS X Japanese keyboards suggest emoji for words along side the Kanji (your ねこ example) and that seems to be the main way the people around me enter them (I'm in Japan). It's easier to use since you don't have to go paging through 20 pages of emoji hunting for a particular one. I have yet to use Android since they added emoji support so I'm not sure what's going on there.

Are the people around you using iphones? The iOS Japanese keyboard suggests a lot more emoji during normal input than the old pre-smart or Android Japanese phones I've used....

Anyway, the main point I'm trying to make is that the method of Japanese language input doesn't seem to adequately explain why emoji are so popular in Japan, because the support for conversion-based emoji input is haphazard even in Japan.

Yes, from what stories are saying.

It may also be in part due to the complexities of asian languages. (Note that this latter part is complete conjecture)

I think more specifically, East Asian languages are based on symbolic characters already, so using emoji is kind of like using a bunch of new characters, instead of being a completely unfamiliar concept.

As someone else mentioned, the two layer input systems used by these languages also make inserting an emoji pretty much the same as typing any other word.

I use them in my apps. Very useful for many situations, and automatically able to handle different scale factors, high contrast modes, etc. Microsoft also has a bunch of useful glyphs in their Segoe UI Symbol font, for the same purpose.

This is offtopic, but I really miss emoji for "shrug" - expression of I don't know and I don't care. They should add something like that to Unicode.


I still have the feeling that emojis in general are an unsolved problem, especially on iOS, where it takes so much time to find a proper "character".

I've seen browsers use a colour font for e.g. mahjong tiles (🀄) already; was that a different implementation, or what?

This reminds me of the customizable shape avatars, like from Halo 2

It's not "the future of color fonts", it's just the present of emoji in Windows. And I really don't like the way they did this.

The technical approach is smart, but lazy, and the resulting emoji look bland and lack definition. No wonder, since this approach doesn't support the way artists work. It's not SVG, it's not PostScript, it's not a bitmap, it's just a glyph sandwich. No opacity, no gradients, no effects. It must be a pain to split your pictures in layers so they can be in a font like that.

As far as using this for text... the novelty of such effects faded out sometime in the 90s when Word Art was all the rage among design-blind office workers.

In the modern world of Unicode, it's even less likely we'll start making fonts with hardcoded layers of cheesy effects when you need to cover a good range of international characters, weights, cursive, hints, kern pairs, ligatures, alternate versions and so on.

> It's not SVG, it's not PostScript, it's not a bitmap, it's just a glyph sandwich. No opacity, no gradients, no effects.

Well thank god. What you call "opacity, gradients, and effects", I call "total inability to be bolded, colored, embossed, etc." Apple's and Google's emoji basically entirely ignore CSS in favor of looking, well, exactly the way they look. Styling emoji to actually fit your site's theme? Who'd have imagined?

You seem so passionate about this, it hurts to break your heart.

When you set your text to be bold, that's a separate font, made by a human hand.

Browsers have a fake bold look when the font is missing, but it's not a look you want on your site. They just, well... smudge it to the right. For Emoji the fake bold look is disabled, because bold or italic emoji is just non-sense on the face of it, so they don't support weight settings.

Also, you can't set the color of Windows Emoji via CSS. They're already colored.

The design of the windows approach to colored fonts actually has affordances for recoloring the text. It's not implemented, but it's mentioned in overviews of the format.

Because the colored glyphs use a palette instead of hard-coded colors, it's possible to assign semantic meanings or names to each palette entry and remap them. This would enable you to render a 'high contrast' version, or adjust the primary color of an emoji (for example, changing the skin tone of a face), etc.

The latter is actually a topic of concern: Most current emoji represent a caucasian or light-skinned individual, so the lack of emojis that represent other races is a problem. People are still figuring out how to deal with it.

I must be getting old because I hate these things. They're the blink tag on steroids.

The main point of the article has nothing to do with emoji. MS's approach to implementing emoji however could lead to a very useable color font format. Read it.

the main point of the article is that these awful things are spreading like herpes.

My phone has color emoji. Facebook has color emoji. Am I missing something?

You obviously didn't read the article.

This solution is totally different, building up the color emoji using a cool font table approach. You should read it; it's worth the time. :)

Actually it is a pretty dirty hack -- it seems ok because the flat design is currently popular. But quite likely gradients and shadows will come back in a few years and then few single-color layers won't be enough.

You could build gradients with this, but it wouldn't look nice zoomed in. And, importantly, Apple's current gradient-filled font wouldn't work!


Seems neat, and I appreciate the forward-thinking mentality. But, as far as I am aware, emoji are a fad and won't really stand the test of time anyway. Either way, I guess, it's nice to see these easy-to-use, easy-to-create principals in play.

Emoji aren't going anywhere. They've been around in Japan for over a decade and have been enshrined forever in Unicode 6.

I thought so too, until I started using them in my messages to my friends and girlfriend. Now I find them an integral part of my communications. 😄

Oh the irony. Your emoji comes out as a blank square for me (Windows 7 - Opera 12)

Chrome does the blank square as well, but it works in Firefox and IE. (win7)

Works for me in FF on Linux.

Consider installing the Symbola font [1]. Where Unicode fallback works correctly, missing glyphs from the regular site font will be taken from Symbola. It's the most comprehensive freely available emoji font I could find (although it doesn't look anywhere as good as full color emojis and at average website font sizes can render a little too small to make out any detail).

[1] http://users.teilar.gr/~g1951d/

Looks good here, IE11 on Windows 8.1

Opera 12 on Debian GNU/Linux shows it fine

A few seem to be really missing the point of this article, which has little to do with emoji itself. TLDR; MS's approach to implementing a color emoji font could lead to a very useable color font format.

EDIT: typos

I think I addressed that in my comment. The article is a little about emoji, and I addressed that too.

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact