How a comment on Hacker News led to 4½ new Unicode characters
unicodepowersymbol.com
unicodepowersymbol.com
It was just a tweak to emoji characters to mark them all as East Asian Full Width instead of Narrow or Ambiguous so that they displayed correctly when using a fixed width font in a terminal console. This probably only matters if you like to use emoji filenames (you mad person), but it felt like a wart so I reported it & had a short back and forth with the chair of the emoji-related subcommittee which resulted in a proposal which was eventually accepted by the committee into Unicode 9.0. The committee were great: took my tiny bug report seriously, wrote huge long treatises to justify the change & eventually voted it into the standard.
(This was pretty much my peak geek achievement of 2016 so far :) )
It's not that I use emoji filenames, it's that I deal with real-world natural language text all the time, including at the console.
(In terms of compatibility, my text-justifying function is going to stop working correctly for the period of time between when gnome-terminal updates to Unicode 9 and when Python 3.x does. Still worth it.)
This is good, actually, because the meaning of a string operation should be consistent when run on the same version of Python.
(If only this applied to the "default encoding". The default encoding should be UTF-8, not whatever you get by asking the user's likely-misconfigured locale. As it is, you can't rely on the default encoding if you want your code to work consistently.)
This comment -- https://github.com/JuliaLang/julia/issues/3721#issuecomment-...
Although I had never worked with the Unicode Consortium, I [submitted a proposal][1] for an international symbol for an observer and it was eventually accepted.
[1]: http://hypertexthero.com/logbook/2015/01/international-symbo...
(Top result: http://www.cbc.ca/news/trending/rifle-emoji-dropped-unicode-...)
Its one thing to have absolute, iron fisted control over your own platform - its another to intentionally seek to limit people's self expression on other platforms by influencing the standard in this way.
One might have a right to do something and yet be wrong to do it.
Apple had every right to do what they did, but they were completely, totally and undeniably in the wrong to do it. Everyone associated with their action should be ashamed. Honestly, they should all resign: their behaviour demonstrates that they have no business being associated with this sort of work.
Obviously not.
There are literally thousands of characters that Apple doesn't encode for their platforms. I haven't heard whether Apple will be supporting:
Osage, a Native American language
Nepal Bhasa, a language of Nepal
Fulani and other African languages
The Bravanese dialect of Swahili, used in Somalia
The Warsh orthography for Arabic, used in North and West Africa
Tangut, a major historic script of China
>The two characters will still be part of the Unicode spec, but they'll be classed as black-and-white "symbols" instead of regular emoji
http://arstechnica.com/apple/2016/06/apple-and-microsoft-pus...
While there was considerable uproar over Emoji and there still often is over yet another fifteen symbols that everyone thinks no one would ever need or use, the bulk of the Unicode character set is still scripts for human languages. And some of those are only relevant for a very small minority, say, archaeologists. But that's fine. There's enough space, we're nowhere near to running out and Unicode enabled all sorts of cool things in computing that simply were not possible before or only with awful hacks and workarounds.
Could you give an example? I don't know anything about this stuff.
That's because every byte stored in the file, for example byte number 188, either means "¼" (as it does in ISO/IEC 8859-1, aka. Latin-1 or ANSI), or it means "ỳ" (as in ISO/IEC 8859-14) or "ｼ" (in JIS X 0201, one of the many Japanese encodings that were devised over the years.)
How do you know which encoding a certain file uses? In general YOU CAN'T and this was the source of many problems and "solutions" which caused even more problems over the years.
Well then, how did you mix symbols from different alphabets, say in a dictionary or in a post that talks about them, like this very post? YOU COULDN'T, short of doing ugly hacks and other subterfuges, like using GIFs for all foreign characters.
Unicode gave a distinct number (or "codepoint") to every character and symbol known to man (within reasonable limits) and this allowed a lot of things that we take for granted nowadays, including this very post, were I just copied and pasted various symbols from their Wikipedia pages and just expect it to work.
Unicode defines normalization algorithms (is é its own character, or e with a modifier character?).
I can have a document which combines English, Russian, Arabic, and Chinese, and expect it to be readable and editable by many different tools.
In this way, new FAQs and other updates spread to all the markets easily.
It's vastly easier to do this stuff when all the documents use the same text encoding. Even if noone can read everything, the fact that everything uses the same encoding means that any pair of languages you can read are technically readable.
2BD2 GROUP MARK 2015-May-05 Accepted 2016-May-29 Stage 6
The bitcoin symbol is in there too.
>The scope of the Unicode Standard (and ISO/IEC 10646) does not extend to encoding every symbol or sign that bears meaning in the world.
>This list has been round and round and round on this -- regular as clockwork, about once a year, the topic comes up again. And I see no indication that the UTC or WG2 are any closer to concluding that bunches of icons should start being included in the character encoding standards simply on the basis of their being widespread and recognizable icons.
>Where is the defensible line between "Fast Forward" and "Women's Restroom" or "Right Lane Merge Ahead" or "Danger Crocodiles No Swimming"?
(http://www.unicode.org/mail-arch/unicode-ml/y2005-m08/0371.h...)
Now it looks they add whatever somebody thinks of. I guess it's related to the liberation from the BMP.
Until Unicode has a half-star character, it won't even be able to encode the average newspaper.
Recent article on the Unicode/emoji debate:
https://www.buzzfeed.com/charliewarzel/inside-emojigeddon-th...
In all seriousness, I'm not sure emoji's really belong in text encoding. Even though it's more convenient, based on where they're most frequently used I don't think they need to be universal.
Text symbols (as opposed to emoji) have different rules. Basically, the symbol needs to be used in "running text" (i.e. normal text), like "containers with [recycling symbol] can be recycled" or "he bid 2[club]". Traffic signs for example are not normally used in the middle of text, so they aren't encoded in Unicode. To get the Bitcoin symbol encoded, I needed to show that it was used in text, not just as a standalone icon. The full rules for symbols in Unicode are at http://www.unicode.org/pending/symbol-guidelines.html
For the snowman in particular, it was added to Unicode because it was a symbol used in the character set for Japanese TV broadcasts, see http://www.unicode.org/L2/L2007/07391-n3341.pdf
TL;DR: Don't argue "Why does Unicode have a poop emoji but no symbol for X?" - the rules are totally different for emoji and symbols.
Edit: does HN strip out arbitrary Unicode characters now? I originally had Unicode characters in place of [recycling symbol] and [club], but they disappeared when I submitted.
The snowman, on the other hand, is a weather symbol for snow, I assume. It appears alongside other symbols for meteorological phenomena, so I imagine was added around the same time and with similar reasoning: http://www.fileformat.info/info/unicode/block/miscellaneous_...
They are mostly in Unicode for use in SMS, but there are plenty of use cases in other forms of text.
Heck, I'd be unhappy. I love adding emoticon and emoji and fun things to my emails.
So why don't we pick a very good set: perhaps every letter in every language in common use for the past 200 years? Then, for the oddball symbols that someone wants to mix in text, there can be some kind of SVG-like convention. This allows publishing textual information without requiring that every device maker updates their device to support a 1-off symbol.
The main purpose of Unicode is to encode the information. How the information is turned into its visual counterpart is outside the scope of unicode. For what it's worth this could be done by linking unicode code points to matching SVGs in a document. Wait, exactly that is already a W3C standard: https://www.w3.org/TR/SVG/fonts.html
Or, put another way:
'We have an unambiguous, cross-platform way to represent “PILE OF POO” (), while we’re still debating which of the 1.2 billion native Chinese speakers deserve to spell their own names correctly.'
https://modelviewculture.com/pieces/i-can-text-you-a-pile-of...
[1] http://www.unicode.org/L2/L2004/04252-khanda-ta-review.pdf
> undue effort on every computer maker, ect, to keep up.
The effort to update the font files every few years? Unless you insist on supporting a new Unicode version the second it comes out, I don't see the big effort here? Of course there is effort for font makers, but this is quite centralised.
So which is it? Does each code point represent a visual image? A semantic meaning? Both? It depends? Something else?
I've tried to decipher that on my own and only learned that the answer to these sorts of questions are complicated, because it's very complicated to represent all written human language via one set of rules.
So I know some of the answers to my questions above, but I'm hoping someone with real expertise can provide the fundamental rules/policies - if there are any.
Look it's pretty simple, every code point represents a semantic meaning, except for:
1. those characters who also encode the width of their visual image (U+FF00..FFEF)
2. the one that means 'unknown' (U+FFFD)
3. those characters that change their visual representation depending on their position in the word (U+FB50..U+FDFF,U+FE70..U+FEFF)
4. those that change the visual image of another code point (U+FE00..U+FE0F)
5. those characters that have a visual image as their semantic meaning (too many to list)
6. those that are designated to have no semantic meaning at all (U+FDD0..U+FDEF)
7. those that have a meaning only in pairs (U+D800..U+DFFF)
8. miscellaneous
"every code point represents a semantic meaning" is completely consistent with the notion that some code points e.g. have differing visual representation depending on their position in the word.
Well the answer is clear: each code point represents one visual image, to which is associated one or more meanings.
For CJK characters, they unified all semantically similar han-characters, even when they have visual forms that are quite different between Japanese, Chinese and Korean.
If you want to write Japanese and Chinese in the same document, you need to mark up the section to tell the system that renders it, to render different visual forms for similar codepoints depending on whether they are used in Japanese or Chinese.
This isn't true. 青 and 靑 are the same character written differently; they have their own codepoints. Ditto for a huge number of simplified Chinese characters; 语 is mainland Chinese and 語 is the same character in Japanese.
I wouldn't know how to show you examples here, as 直 will 直 display the same since they have the same code point, but different number of strokes in japabese and chinese.
https://en.wikipedia.org/wiki/Han_unification#Examples_of_la...
Han characters that are traditionally viewed as variants of one another, or that are simplified from more complex logograms (such as 龜, which was simplified into 亀 in Japan and 龟 in mainland China) tend to have different codepoints, but the stylistically different ones usually belong to the same codepoint.
The emoji code points can be represented differently on different systems given their meaning.
So it makes sense to have different emojis for different 'meanings'.
The 'moon' switch here does no mean 'moon' - it means 'standby' or whatever.
It may look noticeably different on different systems.
Think from a design perspective: you have 5 emojis to represent 'clouds, sky, earth' etc. - and the a different set of 5 to represent 'on, off, sleep, shutdown'. Those icons will be markedly different in terms of representation, groupings, colour coding, underlying functionality if they are integrated into an experience in any meaningful way.
Text your car with the 'shutdown' symbol to tell it to shut down.
Your bot texts your friend with a moon symbol to tell him you're asleep. Or whatever.
So if a system wants to render "on" differently than "straight vertical line", that's possible.
However, if "off" should be rendered differently than "circle", that's not possible. (Or only possible with out-of-band information or modifier characters which would still have to be defined)
It's a mess. If you want to write a document in Japanese that talks about a Chinese character which is written differently than its Japanese version, you can, or can't, achieve this in Unicode, depending on the character, its history, and the mood of the consortium the day it was assigned.
The reality is that Unicode is governed by people, some of those people are grumpy reductionists who push for a minimum of symbols and a maximum of meaning-overloads, and others are more liberal and tend to advocate the opposite, and the result is a compromise, and is in areas very messy.
So? How is that different from any regular character in real life?
101 for example means the number 101, an introductory class in university, slang for "anything introductory" in general, etc.
And let's not get started on the meanings of letters, e.g. a and e.
If people actually used these, it would make searching text for formulae much easier. Wikipedia editors and academic publishers, please note.
Also, there's no Unicode for screwdriver. Perhaps iFixit would like to campaign for that?
Congratulations on getting the power symbols in! When @edent writes "Will update ... when I stop dancing", was it "I got the power"?
I don't see how using them for anything else would have any use. I never searched for units when searching for formulas
BTW, just because a character exist doesn't mean it's the best choice for ordinary use. As https://en.wikipedia.org/wiki/%C3%85#Symbol_for_.C3.A5ngstr.... points out:
> Unicode also has encoded U+212B Å ANGSTROM SIGN. However, that is canonically equivalent to the ordinary letter Å. The duplicate encoding at U+212B is due to round-trip mapping compatibility with an East-Asian character encoding, but is otherwise not to be used.
The idea is one (complex) encoding that will represent the info until the end of time. It creates a lot of trouble, but it's still a good idea.
The standards are not applied consistently. Even leaving emoji out of it, the chinese "character" 囍 never occurs in running text, but there it is in unicode.
FROM MEMORY, a while back there was an article on HN complaining that emoji seemed to magically bypass the requirements other characters needed to meet for inclusion in unicode, and that in fact they were commonly in violation. The taco symbol was called out as an example. I can no longer find this article, but it mentioned the running text requirement, and -- I believe -- specifically indicated that use in names does not count as use in running text. (For an idea of why that might be the case, check out http://tvtropes.org/pmwiki/pmwiki.php/Main/LuckyCharmsTitle .)
HOWEVER, I was not even able to find, on the unicode web site, any discussion of a running text requirement at all, for any kind of symbol. Some example proposals do refer to "running text" by name, but they don't indicate why. The example proposal given for adding characters to an existing block ( http://std.dkuug.dk/jtc1/sc2/wg2/docs/n2934.pdf , suggested as a prototype in http://www.unicode.org/faq/char_proposal.html ) does not mention "running text" at all, and doesn't appear to go to much trouble to document it, although some such documentation is given. The rough guidelines for character proposals at http://unicode.org/pending/proposals.html do not refer to "running text" at all, but they do suggest that, late in the process (specifically, on a proposal summary form, which is different from, and subsequent to, an actual proposal), "references to dictionaries and descriptive texts establishing authoritative information" are required.
I conclude that the Unicode standard's preferred criterion for chinese character inclusion is "would an authoritative chinese dictionary include this character", and while the answer to that question for 囍 is not unambiguous -- a lot of dictionaries don't include it -- it's easy to imagine that some do.
I would appreciate a pointer to the actual running text requirements, as well as what they are supposed to apply to, if anyone can provide that.
> It would be odd not to have an encoding for such a common character.
Outside of its use as a wedding decoration, which is plainly nonlinguistic, how common is it?
The running text requirement is for symbols, so it doesn't apply to Chinese: http://www.unicode.org/pending/symbol-guidelines.html
The word "running" doesn't appear on that page. (Actually, no requirements at all appear on that page; it speaks strictly in terms of strengthening or weakening the case for inclusion, not disqualifying.) Can you explain briefly why that page is evidence that the running text requirement does not apply to Chinese, and where it specifies what the running text requirement is?
Alternatively, what requirements do apply to Chinese, and would they preclude an invented character like one with 女 on the left and 离 on the right?
In this case, the codepoints were added in part because the proposers could show many printed works (user manuals, I guess) that included sentences such as "to turn the foobar on, press the ■ button", which shows that the glyph between "the" and "button" is in some way like the surrounding glyphs. Chessmen were added for similar reasons, even though very few people actually read either user manuals or chess literature.
Then what about §? or $? Or %? The list is endless.
Because the Unicode standards body doesn't want them in, or because those scripts don't have champions pushing for their inclusion?
>On the other hand, approving emoji and random icons delights Westerners.
Westerners? Notwithstanding the fact that emoji icons came from Japan, I'm fairly certain emotive icons are popular globally.
There is also some discussion here - https://news.ycombinator.com/item?id=9219162
In this instance, someone is complaining that they cannot type their name on a computer.
Your fonts don't have to support the entirety of Unicode. That's why we have font stacks and fallbacks.
"To start the device, press the ⏻ button on the device face"
There, used in a sentence.
"Every possible image" (e.g. an elephant icon in running text) is not.
A standard clip art library that covers universally understood symbols sounds like something that would be very useful.
What is "plain text format" though? If 'text' isn't limited to Western ASCII characters (which it very obviously shouldn't be considering many people use other character sets), then the idea of a text standard should be to encode all the glyphs people use, so "plain text format" becomes a canonical list of all the communicative symbols in all languages. That's what Unicode aims to be.
In my opinion, if they're used for communication, it doesn't seem unreasonable that such a canon of characters should include universal iconographic symbols like the standby icon.
This blog post is a nice example, I have absolutely no idea how these new code points are supposed to look like, since I only spend an afternoon to implement the unicode best practices from the Arch wiki, instead of subscribing to some unicode standard mailing list. (Except the one symbol which was redefined to a symbol that does not carry the semantic meaning of "standby symbol" anywhere outside of the unicode standard.)
In my opinion there are two ways forward, one burn the entire thing. Or alternatively, force the unicode committee to produce an authoritative and complete font, in triplicate, and in their own blood.
Meanwhile, a lot of the "Ys and Zs" added to Unicode have proved to be extremely useful. Unicode's math operator and letter-styling support is what made MathJax (and more generally MathML) possible. They've also helped big time when it comes to accessibility (e.g. screen readers) for mathematics on the internet. Should we have shunted that off to another standard and made the creators of screen readers completely restructure their offerings so they can deal with Unicode characters and "Mathicode" characters? Assuming anyone bothered to implement it, how would that be better than just adding a Unicode category and spending a meager amount of space?
Second mathematical symbols, consider the case were I get a text file considering mostly of ASCII 7 and some mathematical symbols which may render as mathematical symbols or as Chinese characters, since there is no way to specify the encoding in a text file and so I have to guess the encoding. (That is not helped by the roughly 17 standardized encodings that mostly agree with utf-8.)
What does that have to do with Unicode adding anything? Are you really claiming that if we threw out Unicode like you recommend, and (if I'm understanding your point correctly) choose an encoding for the new version that looks nothing like ASCII the encoding mess would get better? I think continuing the migration of most transmission of text to UTF-8 and explicitly specifying encodings for everything that needs to stick with Latin-1, etc. is a better option, unless you propose codifying the new encoding in law to force adoption.
Tip: a quicker way is to copy the unrendered box and Google it.
No, last time I checked you are not legally allowed to do that.
In the same way it's useful to standardize letters in various alphabets without standardizing their screen representation. There is semantic content associated with each of these symbols that persists even if there is significant variation in how they are presented. Of the ones you list, emojis are the only ones where this is any more a problematic approach than it is for letters in various alphabets. And as people who don't approve of Unicode adding emojis like to point out, emojis aren't that critical so having some loss in the translation isn't a huge deal.
Remember that before emoji standardization various cell phone manufacturers (particularly in Japan if I remember correctly) started using codepoints for whatever they pleased. The alternative to Unicode not standardizing them was to have a repeat of the OEM font gold rush in the SMP.
> styled math letters (which would have been equally well served by simply rendering them in italics or in a special math font)
That was my first reaction as well, but there are a few problems with that approach:
* Math italic characters look very different from normal italics, and are shaped and kerned very differently because they are commonly used for single-letter variables which will be juxtaposed together in expressions. If your goal is to be able to preserve some math formulas in a purely line based text format, preserving this aspect makes a big difference in readability.
* Many of the math letters and "letter-like symbols" have associated semantic content (like bold for vectors), which it makes sense to preserve. MathML alleviates this to a significant degree but I don't believe these codepoints were intended only for MathML usage.
* On the technical side, OpenType math fonts need to carry associated metadata for many of these characters. Putting them in separate fonts complicates this, since these tables need to refer to glyphs (general codepoints are unsuitable in a number of cases) and each font file would have a different glyph address space.
Things were way worse than that: to add emoji to text, NTT DoCoMo used private-use codepoints, AU used embedded image tags and Softbank wrapped emoji codes in SI/SO escape sequences.
I disagree. Say the name of a letter in any alphabet, and people will draw it in ways that are similar enough for automatic recognition. This is not true for pictograms and emojis.
> The alternative to Unicode not standardizing them was to have a repeat of the OEM font gold rush in the SMP.
I disagree. The alternative is a much simpler and faster standardization, of the kind I offered here: https://news.ycombinator.com/item?id=11958903 There is absolutely no need for a fixed codepoint for most of the non-BMP characters.
> If your goal is to be able to preserve some math formulas in a purely line based text format, preserving this aspect makes a big difference in readability.
So is rendering text in Arial vs. Comic Sans, but they haven't made separate codepoints for those.
Also, where this makes a lot of difference, would count as "specialized usage". I don't think it makes sense to have a single universal standard to standardize all specialized usage of human-readable data.
I think it would have made much more sense to have something like image tags: a special codepoint would introduce a link to a URL containing a sequence of glyphs, followed by an index into that sequence. Those glyphs would be guaranteed not to change (in any meaningful way), and devices would be free to cache them. This way, anything that isn't real text, would standardize representation, too, instead of just a vague "meaning". Another standard could relate those glyphs to one another in some way, giving them standard semantics and means of translation (i.e. "Egyptian hieroglyphics"). This would also allow each of those (emojis or hieroglyphics) to evolve their standards independent of a single universal standard that means little.
The dream of a 16-bit Unicode washed up on the rocks of CJK scripts. It's dead and it isn't going to be revived. You can argue for a simpler standard, with fewer assigned codepoints, but the original BMP isn't it and was never going to be it.
I concede this point. I still don't see why the Unicode Consortium should spend effort standardizing non-text as text.
^1 I am pretty sure that some use cases actually profit a lot, but neither text file formats (since most text does not contain 2^64 different characters zip would work nicely) nor networking (since most data on the internet is either video or torrents) seem to be among them. So probably they would not be huge fields.
I can see the reasoning behind the standard (or very common) symbols or things like emoji, but having every possible glyph in UTF8 seems like a horrible waste.
What if we want to add new glyphs in the next 10 years for emerging standards?
A horrible waste of what? Unicode 9.0 encodes 128,172 characters, of a possible total 1,112,064 code points. The addressable space is 11.52% full. Clearly there's enough left to keep adding more and more characters for a really long time.
If your complaint is that it's a waste of resources, time, etc - surely it's up to the people who are members of the consortium to decide how they want to spend their energy?
[1]https://modelviewculture.com/pieces/i-can-text-you-a-pile-of...
If a number of people who use language "a" know that Unicode isn't handling their language, some of them need to step up and provide a solution. Part of that stepping up might be as easy as complaining about the problems they are running into :-), but eventually for a solution to emerge, some set of people need to step forward and handle the Unicode research and paperwork.
And then what? It's already 11% full.
So all the basics are covered.
We could cover the rest 89% with variations of the turd emoticon and we'll still be perfectly fine.
UTF8 will support it by default, UTF16 will stay broken, UTF32 will break, but nobody uses the later.
I didn't know that UTF-16 was considered broken. In what way is it so?
> What if we want to add new glyphs in the next 10 years for emerging standards?
Then they get added as well.
Just because they are useless to you doesn't mean they are useless to everyone.
[0] Remember this one? https://pbs.twimg.com/profile_images/425274582581264384/X3QX...
That is a meaningless requirement. The symbols I use on a daily basis already don't exist in a single font. Operating systems handle font fallback just fine.
Take this page for example: http://emojipedia.org/faq/ Only a fraction of the emojis is displayed on my laptop. (maybe 20%)
Why would every font need to cover them in the first place? Just one is enough with symbolic characters, sufficient to display them. Text renderers can deal with that.
No font coverage is also fine, at least the data is preserved.
It's nice to have catalogue of symbols and tight encoding for them, but full support of Unicode encoding has very little to do with support for Unicode in an application.
🇦 🇧 🇨 🇩 🇪 🇫 🇬 🇭 🇮 🇯 🇰 🇱 🇲 🇳 🇴 🇵 🇶 🇷 🇸 🇹 🇺 🇻 🇼 🇽 🇾 🇿.
Imagine that you are developing wristband device and you can buy ASIC or FPGA chip module that eats grapheme clusters and spits out bitmap for the right glyph every time.
But some characters not in the BMP I would consider very essential, like the various Asian characters that didn't fit into the BMP.
In fact up to less than 5 years ago, there weren't anywhere except in some phones (and mostly Japanese phones at that).
Thank you for stepping up and making a difference.
In some respect, they are getting jumbled up because of international pressures for the base emoji set to be stretched into a be-all for the global market. An example is Taco. There are tacos in Japan. They are hard to find and when you do find one, you definitely don't want to eat one there. Mexican food is one of the rare cuisines the Japanese don't do better.
> Important symbol additions include:
> 19 symbols for the new 4K TV standard
I am wondering, why did they add symbols for a standard which will become obsolete eventually?
Also, if popular, these kinds of things tend to outlive their technology. For prime examples, look at http://graphemica.com/, http://graphemica.com/%F0%9F%96%AA, http://graphemica.com/%F0%9F%96%AB, and http://graphemica.com/%F0%9F%96%AC (to be fair, I think that is overdoing it)
They were proposed by Japan, and intended for TV electronic program guide. If it makes you happier, one of the symbols is for 8K.
I was actually wondering about the electrical symbols for logic gates, such as AND, OR, NOR, XOR, NOT, etc. I would hope they were universally accepted by now and would help when writing books or describing logic. A quick Duck Duck search revealed nothing...?
Nevertheless, Unicode does have all of the logical symbols from mathematics, which are pretty commonly understood:
∧∨¬⊕Think about it, if you can represent anything human with emoticons. Then you can communicate through emoticons only! Maybe that's what the ancient Egyptians were hopping for?
﷽ 65021 ﷽ FDFD ARABIC LIGATURE BISMILLAH AR-RAHMAN AR-RAHEEM
Seriously, equipment has been marked ON and OFF for a hundred years. Is there any evidence anyone was confused with this more than with O and | ?
And besides, languages the world over use plenty of words borrowed from English, and English itself is loaded with borrow words from other languages.
I've thought the mania for icons to replace common words since the Mac to be silly. Why is a picture of a Kleenex box more understandable than 'PRINT'? I have no idea what half the icons on my iPhone mean.
No way to google icons, either. I know, I'm supposed to learn them by pressing them to see what happens, but as someone who has learned not to learn how to operate machinery that way, I find it distasteful.
http://nymag.com/selectall/2016/04/princes-legendary-floppy-...
I don't know the codepoint for it though. Does anyone (other than the guy mentioned in the article) actually have this 'Prince Font' ?
I see there was a proposal here in PDF:
https://github.com/jloughry/Unicode/raw/master/power_symbol_...
But there's a lot of glyphs there. What was accepted then? If the circle was reused, what are the remaining four?
Well done.
I'll add these (and the IBM-related symbols @kens mentioned, which are specially appropriate) to https://github.com/rbanffy/3270font for the next release (this weekend, I think - still lots of Cyrillic cleanup to do in the develop branch).
On a related note, the main character of my unfinished game [0] will be pleased about this.
Japanese, Oriental, Korean, and Emoji.
It's a bad JOKE.
When do we stop handing out IPv4s by the hundreds of thousands? "When we run out". When do we stop doing 120km/h? "When we run out of road". When do we stop spending money? "When we're flat out broke".
(Note: I am not advocating for or against the unicode case, I'm making a point about the specific mindset used to justify this)
I think the question represents an equally terrible mindset, "when do we stop?" How can I answer that, honestly? Is there a number? Or is it when a certain date has come and gone? How do we pick that number? Or that date? Why do we need to stop? I understand why we might want to rate-limit the adoption of new glyphs, but I don't see why we'd ever draw a line in the sand and say, "Ok, now it's frozen." Imagine if that had happened before the creation of the Euro as a currency.
"Until it's full" reminds me of departments that feel they must spend their entire budget.
Starting to think it should all just be svg
I don't think i personally agree with brand logos in Unicode.
Seconded, brands come and go, as do their logos, many large corporations have gone through several logo changes.
Pan-Am is the main one that springs to mind (or it's because I've just re-watched Blade Runner AGAIN...)
So just change the font you use to render Unicode. The Unicode itself can remain the same.
Surely not every font has to create glyphs for every Unicode character...how does that work? Is there a kind of "fall-back" font for characters not implemented?
A result of this is that if you ask for a character such as "𓀴" (U+13034 EGYPTIAN HIEROGLYPH A044) in a monospace font, the symbol you get back can be variable width.
Many other unicode symbols also suffer from this problem. E.g. ␀ is the printable version of the unprintable NUL (\0) control character, but it's so small at 13.3px / 10pt CSS font size that it's difficult to distinguish from the other control pictures.
␀ ␁ ␂ ␃ ␄ ␅ ␆ ␇ ␈ ␉ ␊ ␋ ␌ ␍ ␎ ␏ ␐ ␑ ␒ ␓ ␔ ␕ ␖ ␗ ␘ ␙ ␚ ␛ ␜ ␝ ␞ ␟ ␠ ␡
How those look on display w/o pixel scaling: https://i.imgur.com/lAAyjXu.png
http://i.imgur.com/kKfLYgx.jpg
Interestingly in Safari the hieroglyph is shown (still small though), I wonder why Chrome can't find it?
The basic problem is that Unicode characters (which may consist of as many codepoints as you like) have varying width. For instance Chinese has characters that are displayed over a width of two normal monospace characters.
See this hacker news post: https://news.ycombinator.com/item?id=10206380
So the problem with emojis is that they aren't really specified to be full width or half width characters: https://ianrenton.com/blog/adventures-in-emoji/
013
034
OSX 10.11.4
Not always true though, and can depend on the application using the right system calls for rendering text (for example).
When did the word "led" disappear from the English language?
I want to strangle "reporters" who write articles for the NYT, Washington Post, etc. who get this wrong all the time.