Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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".



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

Search: