Earlier quoted context omitted.
> Still 16 bits would not be enough, it's only 65536 different code pages, less than half of what is currently in Unicode. But that's only because Unicode has significantly ventured well beyond what we consider to be text. The BMP is enough to represent all text (including math).
BMP is mostly filled with symbols from logographic languages, and currently has around 100 free code points. 16 bits simply isn't enough for the scope of capturing all written language of the history.
How a comment on Hacker News led to 4½ new Unicode characters
171–180 of 429 posts
Re: How a comment on Hacker News led to 4½ new Unicode characters
#172Earlier quoted context omitted.
It actually exists as an official font file published by Prince himself: 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' ?
The article says it replaces capital P (U+0050).
Re: How a comment on Hacker News led to 4½ new Unicode characters
#173At some point, someone realizes that there is need to standardize fixed practical subset of Unicode that contains all essential symbols over the world so that all devices that comply with the standard can __actually__ interchange text in readable, printable and visually presentable form. 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…
Basic Multilingual Plane?
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.
Re: How a comment on Hacker News led to 4½ new Unicode characters
#174Earlier quoted context omitted.
> 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. So you think instituting a system based on links not rotting would better preserve meaning? Not to mention that: * Every text renderer that doesn't support your codepoint now displays…
> Every text renderer that doesn't support your codepoint now displays a full URL, instead of a box, making text using these emojis very difficult to read. It can still display a box. > Instead of making implementation easy by requiring nothing new of text shaping libraries, they now have to be able to both connect to the internet and tie into a file cache. The question is implementation of what . I think that it is…
If it knows about your new codepoint. Everyone using an implementation that doesn't yet support it is going to show the full URL. If history repeats itself, these implementations will be the majority for at least a decade.
> The question is implementation of what. I think that it is not an onerous requirement from applications that need to display emojis or ancient Egyptian hieroglyphs.
Except they need to do literally nothing different. Hieroglyphs are vectorized, and emojis are either bitmapped (which existing font formats already supported) or vectorized. None of this required a single line of code in any text shaping library to change. Text shaping libraries generally don't even need to understand Unicode categories or other metadata: font files already contain all the relevant information (directionality, combining mark, etc.).
> The use of italics in text may also carry crucial meaning. But if a textual representation as sup is supported, I don't see why the specialized rendering should be supported, too, but for math and not plain text.
If you scrub all bold and italics from text, do any of the words turn into different words? That's what happens with sup (or other named operators). Same thing for blackboard letters, fraktur, etc.
> I agree, but I think that that semantic information is preserved when writing N or NN instead of 𝑵 or ℕ. Considering that Unicode isn't enough to write most mathematical formulas convenient forms anyway and requires a specialized renderer anyway, I don't see the reason for this extra effort.
My point is it was better than nothing, which was the alternative when Unicode added these. By adding mathematical characters that worked exactly the same as all other characters, we could get some of the advantages of MathML without needing everybody to implement a special math renderer or learn any new markup, just download new font files.
If getting everyone to accept MathML or something similar in an expedited fashion was a reasonable proposition, then I might agree that they should've kept it out of Unicode. Those were not the facts on the ground when this decision was made. Note that even now that we have MathML, the few browsers that support it (IIRC Firefox & Safari only) have complete shit implementations that look terrible.
The crux of this is that making changes to a standard to support something new and propagating the changes is super hard; getting new standards to get accepted and implemented is a Herculean effort. Unicode's expansion into these domains required nobody to do anything differently, let alone decide to up and write an implementation of a completely different standard. I think this is a case were our alternative was to let the perfect be the enemy of the good, or at least the working.
Re: How a comment on Hacker News led to 4½ new Unicode characters
#175Earlier quoted context omitted.
Is it? Couldn't Unicode have pointers or links, where a codepoint "exists" with no content and only links to another? (I don't know anything about Unicode, so maybe it already has that.)
Semantically, yes. In the code tables you'll see that that "opposite" symbols have links to each other. Programatically, it is much easier to say "does a character lie between 0x12 and 0xBC" than to create a function like `isSymbolForTrafficInEurope()`
(And relevant to my country, "Swedish characters lowercase" would map to latin letters lowercase + åäö.)
Re: How a comment on Hacker News led to 4½ new Unicode characters
#176Earlier quoted context omitted.
Text files growing by 8x would be a non-starter. It would be nice to standardize on something but what do you have against UTF8?
It's not bad, but it's complicated, as it requires an O(n) algorithm to jump to a specific character. Unicode should have been capped at 16 bits, and doubling text files in size is fine. An alternate representation of simplified UTF-8 would have kept compatibility with old ASCII files.
Re: How a comment on Hacker News led to 4½ new Unicode characters
#177Earlier quoted context omitted.
I hear you. If you want pictures then use a markup language. Unfortunately it is too late now. We finally had an almost universally supported character set, and then we ruined it with levitating men in business suits. Recent Unicode versions introduce far more technical challenges than they solve. For instance, now that code points can come with colour, there are conflicting requirements between the requested text co…
This is about icon fonts and font rendering and has nothing to do with Unicode. Code points don't have colour; there's no colour requirements anywhere in the spec. Your fonts don't have to support the entirety of Unicode. That's why we have font stacks and fallbacks.
Re: How a comment on Hacker News led to 4½ new Unicode characters
#178Earlier quoted context omitted.
> Every text renderer that doesn't support your codepoint now displays a full URL, instead of a box, making text using these emojis very difficult to read. It can still display a box. > Instead of making implementation easy by requiring nothing new of text shaping libraries, they now have to be able to both connect to the internet and tie into a file cache. The question is implementation of what . I think that it is…
> It can still display a box. If it knows about your new codepoint. Everyone using an implementation that doesn't yet support it is going to show the full URL. If history repeats itself, these implementations will be the majority for at least a decade. > The question is implementation of what. I think that it is not an onerous requirement from applications that need to display emojis or ancient Egyptian hieroglyphs.…
And that's what happens when scrubbing subscripts or binomial coefficients. When you want to represent math as text, you need to change your representation (add multiplication signs, forgo subscripts, use confusing parentheses etc.). This is still true with Unicode. The contribution of the non-BMP special math characters is quite minimal.
> The crux of this is that making changes to a standard to support something new and propagating the changes is super hard; getting new standards to get accepted and implemented is a Herculean effort.
Sure, but the emoji craziness continues, and there's little sign it would ever stop. Instead of saying "this isn't text; if you want, call it 'special text', escape it, and let a different body standardize it", the body entrusted with standardizing text representation worries about how to represent a picture of two people kissing as text. What next? Kids would want to add tunes to their text messages. Would the Unicode Consortium add code points for MIDI? And maybe managers would want to standardize code points for organizational diagrams. Would that be the consortium’s responsibility, too? The BMP contains all the characters for reasonable text-art.
Re: How a comment on Hacker News led to 4½ new Unicode characters
#179Earlier quoted context omitted.
It's not bad, but it's complicated, as it requires an O(n) algorithm to jump to a specific character. Unicode should have been capped at 16 bits, and doubling text files in size is fine. An alternate representation of simplified UTF-8 would have kept compatibility with old ASCII files.
Emojis and hieroglyphs aside, 16bit was not enough for CJK characters. It's a real world problem---a character set that can't spell people's name or location can't be universally adopted.
Re: How a comment on Hacker News led to 4½ new Unicode characters
#180Earlier quoted context omitted.
Unicode should not be viewed as a standard clip art library. A standard clip art library that covers universally understood symbols sounds like something that would be very useful.
It absolutely would be. But it should not be part of a plain text format.
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.