Live data from Hacker News

Unicode Standard, Version 12.0

blog.unicode.org

21–30 of 56 posts

Re: Unicode Standard, Version 12.0

#21
post #9

Earlier quoted context omitted.

Do you think that the committee approving new emojis is qualified to seamlessly transition into discussing the minutiae of cuneiform formatting? It may be a guess on my part, but I'm pretty confident that there are two different (and probably non-overlapping) sets of people working on these two areas.

Perhaps Unicode could solve the emoji problem once and for all by providing a mechanism for encoding arbitrary .svgs as multi-kilobyte strings of modifier characters.

Emojis started being included in Unicode because they were already in the text encodings used by Japenese SMS. Multi-kb glyphs wouldn't exactly fly in SMS.

Re: Unicode Standard, Version 12.0

#22
post #7

It is a shame that the majority of these won't been seen by common devices. Google has stopped work on their Noto fonts initiative, and modern versions of Android are stuck with pre Unicode 10. Apple has been pretty good at adding Emoji on iOS, but macOS seems to be left behind. As for Linux... Installing the Unifont gives coverage, but most distros don't seem to have a way to update base level fonts. I'd love to be…

Emoji handling on Linux is so upsetting. It should not be this tricky.

I submit that it should: http://baldi.me/blog/emoji-in-sql

Re: Unicode Standard, Version 12.0

#23
post #16

Are the more fancy scripts supported by Unicode used by real people in production? By scholars? With special fonts? Or is it more like Unicode just wanting to support everything, even though the target audience is actually using something else? Asking because I'm impressed by the aim of the whole Unicode project but having no real experience with it beyond the basics.

Mostly scholars. But even if nobody at all would be using it currently, the explicit goal of Unicode is to support all scripts. Unicode is meant to make all other text encodings obsolete so the world never has to think about text encodings again (which mostly worked so far). That goal can only be reached/maintained if every script anyone might plausibly want to use is contained in Unicode.

More specifically, scripts and glyphs that have documented and valid use cases. If you made up a script today, you would have to start using it first (and gain acceptance of it in some community) before it would be eligible for inclusion in the Unicode standard. A good example is the power symbol (⏻, Unicode 9.0). The proposal for it neatly documented that it was in wide use already — in manuals in particular.

Emoji are a slightly different beast though. Those seem to get included based on projected use cases.

Re: Unicode Standard, Version 12.0

#24
post #16

Are the more fancy scripts supported by Unicode used by real people in production? By scholars? With special fonts? Or is it more like Unicode just wanting to support everything, even though the target audience is actually using something else? Asking because I'm impressed by the aim of the whole Unicode project but having no real experience with it beyond the basics.

You will need a "special" font to visualise the text but depending on the writing system it may be enough for someone to simply make one new glyph for each of the characters in your system and add it to a general purpose "everything" font. For some writing systems you need more powerful technology because e.g. the system has complicated rules about how shapes fit together and are transformed by adjacent shapes.

For practical purposes there isn't "something else". We're well past the point where Unicode was adding things that worked fine on a specially modified edition of Microsoft Windows for the specific language (like Dungan, which needs extra characters not normally used in Cyrillic) or whatever, these are now often _really obscure_ writing systems where previously you'd only put them "on a computer" by uploading a picture of the writing. Now the computer can handle them as text because they're in Unicode.

For all the historical writing systems, and some of the minority systems that have very few users many of whom know another language that is more widely used and thus more useful to them in practice (imagine going on a forum to ask a question about maintaining the motor sledge you use, you know Russian and also Dungan - obviously you will ask in Russian, because that's a LOT more people who might answer) - in practice the new scripts in Unicode will only be used by academics to transcribe stuff. It still makes that easier, because they can use Unicode everywhere, not just in specialist tools that maybe another researcher built for the language they care about.

Re: Unicode Standard, Version 12.0

#25
post #7

It is a shame that the majority of these won't been seen by common devices. Google has stopped work on their Noto fonts initiative, and modern versions of Android are stuck with pre Unicode 10. Apple has been pretty good at adding Emoji on iOS, but macOS seems to be left behind. As for Linux... Installing the Unifont gives coverage, but most distros don't seem to have a way to update base level fonts. I'd love to be…

That's fine though. On Linux distributions care is usually taken to ensure fonts that cover all languages in common use today, but there is no need to cover every glyph in the standard right from the start. Some Unicode blocks eventually get a default font, some are so specialistic that you have to install a special font, but that's perfectly doable.

Newer versions of distributions tend to come with updated versions of the fonts installed, so eventually support will increase.

Re: Unicode Standard, Version 12.0

#26
post #8

Earlier quoted context omitted.

The whole emoticon thing have became ridiculous. It's time for Unicode to split and let the kids playing with their images and to focus on more important, textual things. For example the cuneiform block is not detailed enough to be used by scholars.

In what way is the Cuneiform block insufficiently detailed?

Variants. There is a lot of differences in the form of characters given time and place and writing. Scholars want to be able to reproduce text with fidelity so the current standard is insuffisant for them (I heard that from a scholar in that field). In a way it is similar to the issue created by Unihan. Abstractly the unified characters are 'the same' but people still want to see them displayed with a given shape.

Re: Unicode Standard, Version 12.0

#27

Earlier quoted context omitted.

Perhaps Unicode could solve the emoji problem once and for all by providing a mechanism for encoding arbitrary .svgs as multi-kilobyte strings of modifier characters.

Emojis started being included in Unicode because they were already in the text encodings used by Japenese SMS. Multi-kb glyphs wouldn't exactly fly in SMS.

I dunno, by wildly extrapolating current trends, by 2050 a typical text-based message will already consume several MB of bloat, Javascript, subliminal advertisements, superliminal advertisements, JSONs encoding XML encoding JSONs encoding base64 encodings of..., 128-bit float variable font settings, prayers to the Packet Gnomes, and more Javascript.

In comparison, a few extra kb won't seem so bad.

Re: Unicode Standard, Version 12.0

#28
post #9
post #8

Earlier quoted context omitted.

The whole emoticon thing have became ridiculous. It's time for Unicode to split and let the kids playing with their images and to focus on more important, textual things. For example the cuneiform block is not detailed enough to be used by scholars.

Do you think that the committee approving new emojis is qualified to seamlessly transition into discussing the minutiae of cuneiform formatting? It may be a guess on my part, but I'm pretty confident that there are two different (and probably non-overlapping) sets of people working on these two areas.

Of course I know this is two different committees. I'm not talking about that level of separation but splitting Unicode in Unicode proper and the emoji in another standard. Emoji standardisation is orthogonal to encoding present and past writing systems once the set of existing Japanese emoji were encoded. So it became a shit show as soon as the standard created previously non-exiting characters as emoji. In comparison, if you create your own alphabet it won't be included, so newly created emoji should be treated in the same way: being excluded of the standard.

Re: Unicode Standard, Version 12.0

#29

Earlier quoted context omitted.

Mostly scholars. But even if nobody at all would be using it currently, the explicit goal of Unicode is to support all scripts. Unicode is meant to make all other text encodings obsolete so the world never has to think about text encodings again (which mostly worked so far). That goal can only be reached/maintained if every script anyone might plausibly want to use is contained in Unicode.

More specifically, scripts and glyphs that have documented and valid use cases. If you made up a script today, you would have to start using it first (and gain acceptance of it in some community) before it would be eligible for inclusion in the Unicode standard. A good example is the power symbol (⏻, Unicode 9.0). The proposal for it neatly documented that it was in wide use already — in manuals in particular. Emoji…

They used to be included because the Japanese had them in their encoding systems, but the situation now is far more fuzzy. Which is odd for a standard.

Re: Unicode Standard, Version 12.0

#30

Earlier quoted context omitted.

Perhaps Unicode could solve the emoji problem once and for all by providing a mechanism for encoding arbitrary .svgs as multi-kilobyte strings of modifier characters.

Hmm, they did include that block for encoding arbitrary bitmap images. (U+2800)

U+2800 etc. is for Braille, which is an alphabet. Nothing to do with bitmaps.
Post reply on HN