What does Unicode support actually mean?
boyter.org
boyter.org
The last bit is wrong, at least in French. The upper case representation of “côté” is “CÔTÉ”. It infuriates me to no end that Microsoft does not accept that letters in caps keep their accents. I can believe that it might be language-dependent, though.
Also, a search engine that does not find “œuf” when you type “oe” is broken.
Very interesting article, though. I wish more developer were aware of this.
That behaviour is actually locale-dependant in Microsoft apps. Setting Microsoft Word to "French (Canada)" uses accented capitals, while "French (France)" does not.
I imagine there's a lively internal debate about the latter. France's Académie Française actually says the behaviour you'd prefer is the proper one, but the local typographic culture is heavily influenced by a history of typewriter use where such accents weren't available.
There are dozens of us! Dozens! ;-)
There isn’t any debate really, in the sense that virtually nobody remotely interested in typesetting advocates for unaccented caps. All the french books on typography and spelling emphasise that accents change the meaning of words and that they should be kept, provided that you have a device that supports them. It’s just an urban legend amplified by stupid defaults in commonly-used applications.
Right, I’m going to stop ranting now :)
In uni, for the typography class, the learning material had a nice capital "PALAIS DE CONGRES" on the first page, suggesting a building full of eels.
I guess most Germans are not aware of these differences and would expect that Ctrl+F treats them the same.
Also, as a Finnish user, I would not be impressed by a search for "talli" (stables) matching "tälli" (blow), or "länteen" (westwards) matching "lanteen" ('of the hip').
In the US, there's starting to be more push from people with ñ in their name to get support for the correct letter, but most government systems have zero support for anything but ASCII all capitals (sorry McWhoever).
On mine (77.0.1) it finds the OP's "The German character ä" as well as yours. Conversely, searching for "The German character ä" finds the OP's original and your "a" version. There is a "match diacritics" button for enabling/disabling this behavior.
Normalisation and - except for the soft-hyphen - ignoring of ignorable whitespace characters (ZWNJ, ZWJ, WJ etc.) on the other hand are still missing in Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=640856).
The number of times, in actual real life, that the inconvenience of the ambiguity outweighs the convenience of the overlap are not many.
YLMV.
...and now that I've complained about it I notice that there are extensions to enable regex search in the browser itself, nice
Of course all of this is locale-dependent and it might be acceptable for ease of use to match "ä" to "a" for international users. But not in a german locale.
Proper I18N is very hard, and supporting Unicode is just a first step. Converting text between lower/upper/title-case can only be done knowing at least the locale of the text, and in rare cases a case-folding-roundtrip can even change the meaning of the text, so you will have to be able to speak the language.
This is unworkable, since "Busse" (several autobuses) should not match "Buße" (repentance). But "Busse" (incorrect spelling of "Buße" due to character set limitations/Swiss German spelling I believe) should match "Buße" by your argument.
Anyway, modern Firefox lets you choose whether to match "Apfel" against "Äpfel".
But: "Busse" is not a always incorrect spelling, it's just an "emergency" one, if you really can't use "ß" for some reason. One example is allcaps text, here "BUSSE" and "BUSSE" are not distinguishable, although they have different meanings. Also, there is Swiss German, where replacing ß with ss is the normal form and not at all "accepted in an emergency" like in German German: https://www.galaxus.de/de/page/schweizerhochdeutsch-fuer-anf...
Incidentially this is one of the instances where you really have to know the language and the context to be able to do a lowercase -> uppercase -> lowercase roundtrip, otherwise you might screw up with "Buße -> BUSSE -> Busse", changing the meaning. Or not, if the current locale is de_CH instead of de_DE.
Together, since very often search will be case-insensitive, I think that while you may be correct, being as strict as to not match here would not be what the user would expect.
Yes, again, I18N is hard and sometimes it is impossible to do correctly for a machine.
Szene should match ß?
Also, in this case, Sz is pronounced as the two distinct letters it is composed of. Whereas when "sz" replaces "ß", the pronounciation is just very similar to a plain "s".
Admittedly German isn't my first language. But it seems odd to be permissive in one case, but more restrictive in the other. In my experience there are two cases for searching: exact matches, like you'd expect an editor's find and replace, and more permissive searches, where you might expect to skip through several matches to find what you're looking for. In this second case, what's the advantage of being more exclusive in one case, then less exclusive in the other? Why not have a more permissive default (as mentioned by the other user's reply regarding Firefox's configurable search), even if it's technically incorrect?
Whereas for umlauts ä, ö and ü, the forms with ae, oe and ue are always "emergency replacements", even the Swiss use äöü very frequently (though not always). Also, there are almost never ambiguities when replacing ä, ö, ü -> ae, oe, ue. Yet there are very frequent ambiguities when replacing ä, ö, ü -> a, o, u, because singular/plural, conjunctive and other forms are derived that way and sometimes there are just different words that only differ in one vowel being an umlaut.
So there is a difference in the chance of being wrong when picking one form of a word for another possibly equivalent one. When you do ss == ß, you are often correct. When you do ä, ö, ü == ae, oe, ue, you are almost always correct. When you do ä, ö, ü == a, o, u, you are almost always wrong.
requires, not just "allows".
> even the Swiss use äöü very frequently
I can't think of any case where Germans would use one of these and German speaking Swiss would not. But as another Swiss peculiarity, some of our words contain "üe", e.g. "Üetliberg", "gmüetlich".
But, regex is a separate issue than languages of text.
There is only one key ä on the keyboard, the user probably doesn't have a choice whether that enters the single character version or the two-character version...
Why? That is horrific! They are different letters. Why would you ever need that?
I have no idea. I don't speak Greek, and I am not familiar enough with its alphabet. The question, I suppose, is if there's a reasonable/intuitive enough mapping between the Greek and the Latin alphabet that it would be possible to search for Greek words using a non Greek keyboard. If yes, then I suppose my answer would also be yes - but I'm happy to be corrected by someone who is actually speaks Greek.
My point is that when it comes to things like searching, usefulness trumps purity. I search because I want to find shit. Not because I want to get perfect feedback on linguistic details from my software.
Usefulness of such behavior is objectionable. Characters with and without diacritics are different graphemes, part of different words. If i search something, i do not want to get plenty of irrelevant results. Just that happened to me few days ago, when i entered a rare word root to search box in Firefox and was surprised that got plenty of irrelevant results because there was common word differing in diacritic marks.
Even if sometimes there is a text written without diacritic marks where there should be, it is usually consistent for whole document, so if i search some word that contain diacritics, i know whether to enter the word with or without it.
I can imagine cases where enough context is available and you can only do the actually usable search. Heck, even Google doesn't give you any option, though I frequently hate that.
"Any self-respecting" -- this is very, very hard. If you are Danish, your keyboard most likely has a way to enter Ø and you would expect Ø and O to be handled as two different letters. However, if an English article mentions the Øresund bridge, it's not unreasonable to expect a search on Oresund to match it. Or, in Hungarian, "kor" means period or age, "kór" means disease and "kör" means circle... but searching for "kor" in Chrome finds all of them. And Unicode won't save you: Ø does not have decomposition rules but ó and ö both do. So the common practice of decomposing - removing marks - recomposing route can either be too little or too much. The upcoming solution for Drupal will allow users to edit remove diacritics rules per language, no other way to do it.
This is Libreoffice taking that path, I know Firefox does the same: https://cgit.freedesktop.org/libreoffice/core/commit/?h=libr... see the icu::Transliterator::createInstance("NFD; [:M:] Remove; NFC", part.
In the last stage, a full DWIM-AI would do the matches. ;)
I once worked on what we called DYM tools (for "Did You Mean"). The goal was to assist native English speakers who were learning a second language find words they heard, in that language's electronic dictionary. We knew, for example, that native speakers of English have difficulty distinguishing the dental and retroflex consonants of Hindi, so the DYM allowed mismatches of those. A perfect spelling was at the top of the list returned from the dictionary, while a misspelling--such as writing a dental for a retroflex--resulted in the mismatched word being a little lower in the list. We tailored our DYMs for particular target languages (and always for native speakers of English). As you say, getting something like this to work for multiple languages at the same time would be difficult.
However, I cannot get it to find my friend Nikolay when I type the whole thing, as it doesn't match the final Cyrillic letter with my "y".
I would say, in general, string matching leaves a lot to be desired, especially when I don't know how to actually type most of the letters of my colleagues's and friends's names. (It's easier on Mac than Windows 10 though - I can't figure out a dang thing for Windows 10 that is not English.)
é is just a different accent of e, not a different character in the alphabet. ä is a completely different character in my alphabet. Similarly ö is a completely different character in my alphabet and should not be considered equal to o, if the text is Swedish.
For someone in the US or France, the ö or ë probably is just a pronounciation diacritic as in Raphaël or Cooöperation. Of course an American doing Ctrl+F on a website (Likely New Yorker!) would want to find "Coöperation" when searching for "Cooperation". Even weirder: when I go to the New Yorker and search for Cooperation I want to find "Coöperation" too!
So this is highly context dependent. Ideally I want collation/comparison to depend on the content of the page, not my browser/OS language.
Another idea would be to do that in Swedish text, "é" will always be represented in decomposed form, while "ä" will always be represented in precomposed form, so that you can tell the difference.
<blockquote lang="sv">...</blockquote>I'd even suggest browser to mess up formatting of non English letters (by using wildly different fonts) to encourage better semantic markup, but it is a bit hard-core and everyone would shout "compatibility breakage" at them :)
As long as it is user configurable which fonts to use for which language, I think that it does not break compatibility to do that. Actually, I think it is a bit good idea. The document should only specify the language and the style (e.g. bold, emphasis, normal, fix pitch, heading, etc) and then that combination is mapped to a font in the browser. (If the user has enabled use of CSS fonts, and such fonts are specified, then they would override those specified by the user. If the user has not enabled use of CSS fonts, then the user's fonts are always used.) This would be needed anyways due to the Han unification that Unicode does, anyways (and Unicode is very messy, anyways). (I mentioned before that Unicode can be good for searching, and if that is what you are doing with Unicode rather than for writing and displaying documents, then Han unification is probably desirable, although again the Duocode that I mentioned before may help even more.)
The correct way to handle this is by tagging the text with a language tag, as has been mentioned in other replies to the parent post.
If you're going to have a "smart" search that decides to mesh these together, the option to turn off the "smartness" should be right there.
Which is to say, just getting everything onto UTF-8 (or UTF-16 if you must) would be a huge win.
[1] https://en.wikipedia.org/wiki/ISO/IEC_8859-1#Quotation_marks
Oh, it's worse than that. There can be locale specific tailorings of case folding rules.
By the way, do not confuse case-folding mappings with case mappings for up- and down-casing. These are different in Unicode.
Also, don't think this is Unicode's fault. This is the fault of humans for creating such rich scripts and languages and rules.
Can't tell if serious or not
At first I though "this must be a joke", but then I though, "well, it can make sense in some contexts".
And now I don't know if I'm fool or not.
Double letters being a single letter isn't rare, such as ll and dd in welsh. In a strange sense it arguably occurs in english in th and th, which I could argue are double-letter representations of single letters, which were originally eth and thorn
I did! That was the first thing I said.
> > characters that render as whitespace but aren't, for example U+2800 (BRAILLE PATTERN BLANK).
> in actual braille, that is a whitespace character
Horizontal whitespace characters [ \t\xA0\u1680\u180e\u2000-\u200a\u202f\u205f\u3000]
Vertical whitespace characters [\n\x0B\f\r\x85\u2028\u2029]
Whitespace characters [ \t\n\x0B\f\r]
> > Yeah we support emojis, so yes we support unicode!
And sometimes it's not even that simple, because things that say they support UTF-8 can't encode the full range.
Looking at you, MySQL and "utf8mb3"
- UTFs
- [canonical] equivalence (form, normalization)
- [canonical] decomposition
- [canonical] precomposition
- case mapping
- case-folding
- localization
- the reason for all this complexity
(hint: it's not the UC's fault)
> - the reason for all this complexity
> (hint: it's not the UC's fault)
But, yes, with the possible exception of normalization, all of those are things you'd need to deal with in some fashion regardless of Unicode.
First off, diacritical marks have generally been just that: marks that get added to other characters. Notionally that is a great deal like combining codepoints. For example, typewriter fonts, and later ASCII, were designed to have useful overstrike combinations. So you could type á as a<BS>', both in typewriters and in ASCII! Yes, ASCII was a variable-length, multi-byte internationalized encoding for Latin scripts. For example, this is why Spanish used to drop diacritical marks when up-casing: because there was no room in those typewriter fonts for accents on upper-case letters, though nowadays we have much more luxurious fonts, and so you see marks kept on up-cased Spanish a lot more than one used to.
Second, diacritical marks as combining marks adds a great deal of flexibility and a fair degree of future-proofing to the system. This is a restatement of the first point, I know. Read on before telling me that flexibility is nice but expensive.
Third, it is much simpler to close canonical composition to new compositions by having canonical decomposition than it is to keep adding pre-compositions for every sensible and new character. Part of this is that we have a fairly limited codepoint codespace while pre-compositions are essentially a cartesian explosion, and cartesian explosion means consuming codepoint codespace very quickly. Cartesian explosions complicate software as well (more on this below). This really gets back to the point about flexibility.
Fourth, scripts and languages tend to have decomposition strongly built into their rules. It would complicate things to only let them have pre-composed characters! For example, Hangul is really a phonetic script, but is arranged to look syllabic. Now, clearly Hangul is a lot more like Latin in terms of semantics than like Hiragana, say, so you should want to process Hangul text as phonetic (letters) rather than syllabic, but the syllabic aspect of it can't be ignored completely. So Hangul gets precompositions (lots, thanks to cartesian explosion) but even in NFC Hangul is decomposed because that is much more useful for handling in software.
Emoji are mostly like ideographic CJK gluphs, except with color. The color aspect is what truly makes emojis a new thing in human scripts, but even color can be a combining mark. Emoji clearly illustrates the fact that our scripts are still evolving. This is a critical thing to understand: our languages and scripts are not set in stone! You could say that there was no need to add emoji all you want, but they were getting added in much software, and users were using them -- eventually the UC was going to have to acknowledge their existence.
Aside from emoji, which are truly an innovation (though, again, not the UC's), conceptual decomposition of characters had long been a part of scripts. It was there because it was useful. It's entirely natural, and a very good thing too, that it's there in Unicode as well. Decomposition, and therefore combining codepoints, was probably unavoidable.
Regarding digraphs and ligatures, these too are part of our scripts, and we can't very well ignore them completely.
This is not to say that the UC didn't make mistakes. Han unification was a mistake that resulted from not inventing UTF-8 sooner. Indeed, the UC did not even invent UTF-8. Some mistakes are going to be unavoidable, but decomposition and combining codepoints are absolutely not a mistake.
Finally, we're not likely to ever replace Unicode -- not within the next few decades anyways. However much you might think Unicode is broken, however widespread, right, or wrong that perception might be, Unicode is an unavoidble fact of developers' lives. One might as well accept it as it is, understand it as it is, and move on.
Combining diacritics are a good thing, I'm talking about Unicodes conflation^W deliberate lies that a code point is a meaningful unit of data in it's own right rather than a artifact of using a multi-level encoding from characters like "ä" to bytes like "61 CC 88".
> For example, this is why Spanish used to drop diacritical marks when up-casing: because there was no room in those typewriter fonts for accents on upper-case letters
Huh, I remembered that, but though it was some badly-designed computer typesetting system.
> Third, it is much simpler to close canonical composition to new compositions by having canonical decomposition than it is to keep adding pre-compositions for every sensible and new character.
Yeah, this is what conviced me that base+diacritic was a better design than precomposed characters.
> Emoji are [...] with color.
That - that they are not actually text - is one of several problems with them, yes.
> but decomposition and combining codepoints are absolutely not a mistake.
Decomposition and combining diacritics are not a mistake. The mistake is treating the decomposed elements as first-class entities.
> Finally, we're not likely to ever replace Unicode -- not [soon] anyways.
That has been said about literally every bad status quo in the history of problems that existed long enough for people to compain about them.
"The dragon is bad!"[0], and no amount of status-quo bias is going to change that.
What on Earth are you talking about. Where does the UC "lie" like this? Remember, the base codepoint is generally a character in its own right when it's not combined, and combining codepoints are mostly not characters in their own right.
> Yeah, this is what conviced me that base+diacritic was a better design than precomposed characters.
If anything, precompositions probably exist primarily to make transcoding from other previously-existing codesets (e.g., ISO-8859-*) easier.
> > Emoji are [...] with color. > > That - that they are not actually text - is one of several problems with them, yes.
How are Kanji text and emoji not? Both are ideographic. What is the distinction? This is not rhetorical -- I'm genuinely curious what you think is the distinction.
> > but decomposition and combining codepoints are absolutely not a mistake. > > Decomposition and combining diacritics are not a mistake. The mistake is treating the decomposed elements as first-class entities.
The base codepoints are generally characters in their own rights ("first-class entities") while the combining ones are generally not. In what way am I getting that wrong?
> > Finally, we're not likely to ever replace Unicode -- not [soon] anyways. > > That has been said about literally every bad status quo in the history of problems that existed long enough for people to compain about them.
You are making arguments for why Unicode should be replaced, though I think they are unfounded, but you'll need more than that to get it replaced. Even granting you are right, how would it be made to happen?
The Unicode standard originally defined "character" as a code point (not vice versa), and until less than five years ago I could not have a discussion about the differences between characters and code points (and why the latter are bad) without some idiot showing up to claim there was no difference, since Unicode defined them to be same. However on looking for a citation, it seems that http://www.unicode.org/glossary/ does not actually support that claim (although bits such as "Character [...] (3) The basic unit of encoding for the Unicode character encoding" do little to oppose it). So I can't actualy prove that the lies of said idiots were deliberate on the part the UC. Which is to say I was mistaken in assuming that equivalence to be deliberate lie rather than a miscommunication (probably).
> How are Kanji text and emoji not?
Kanji are monochrome and can be written with physical writing implents such as pencils. Emoji aren't and can't; a chunk of graphite can't make green and purple marks for a image (not character) of a eggplant.
> I'm genuinely curious what you think is the distinction.
Apologies, I should have been a bit more explicit there.
> The base codepoints are generally characters in their own rights
And to extent that that's the case, we should, where possible, be talking about the characters, not the implement details of representing them.
> Even granting you are right, how would it be made to happen?
No idea, but I'm not inclined to pretend something isn't bad just because I can't do anything about it.
I started having to deal with Unicode back around 2001. Even back then the distinctions between code unit, codepoint, character, and glyph, were all well-delineated. Very little has changed since then, really, just more scripts, some bug fixes, and -yes- the addition of emoji,
> Kanji are monochrome and can be written with physical writing implents such as pencils. Emoji aren't and can't; a chunk of graphite can't make green and purple marks for a image (not character) of a eggplant.
I mean, cave paintings were color and kinda ideographic, and you do know that you can use colored crayons/pencils/pens/paint/printers to make colored text, yes? :-)
I'm sure you can make a monochrome emoji font. In a few thousand years we might evolve today's emoji to look like today's Han/Kanji -- that's what happened to those, after all!
Seriously, I can't see how color is enough to make emoji not text. Kids nowadays write sentences in Romance languages and English using mostly emoji sometimes. It can be like a word game. In fact, writing in Japanese can be a bit like a word game.
Animation begins to really push it though, because that can't be printed.
> And to extent that that's the case, we should, where possible, be talking about the characters, not the implement details of representing them.
And we do. We talk about LATIN SMALL LETTER A and so on. Yes, U+0061 is easier sometimes.
> No idea, but I'm not inclined to pretend something isn't bad just because I can't do anything about it.
Fair. Myself I think of Unicode as... mostly faithful to the actual features of human written language scripts, with a few unfortunate things, mostly just Han unification, UCS-2, and UTF-16. Honestly, considering how long the project has been ongoing, I think it's surprisingly well-done -- surprisingly not-fucked-up. So I'm inclined to see the glass as half-full.
Let's put it this way: there are a lot of mistakes to fix once we get the time machine working. Mistakes in Unicode are very, very far down the priority list.
I don't remember the date, but I first had to deal with unicode when it was a 16-bit encoding (pre- surrogate pairs).
> I mean, cave paintings were color and kinda ideographic
Sure, but they weren't text, which is what we were actually talking about.
> you can use colored [whatever]
That's a property of the rendering, not of the characters; eg <font color=red>X</font> is a colored font tag containing a non-colored character (er, a character without color information), not vice-versa.
> Let's put it this way: there are a lot of mistakes to fix once we get the time machine working. Mistakes in Unicode are very, very far down the priority list.
That's fair; I have a very long and very angry priority list, but I was mainly just objecting to
> all [rather than some] this complexity [is] not the UC's fault
and grabbing a couple of specific examples off the top of my head.
(Although now I realize I never got around to complaining about zero-width joiner, or 'skin tone' modifiers, or parity sensitive flag characters, or...)
So there would be a Japanese Kanji that looks similar to, but distinct from, a Chinese character. And both would be encoded as the same character in Unicode. And that character would look one way when included in a Japanese document and another way when included in a Chinese document.
If the document contains both Japanese and Chinese, and the character appears in both parts, would a Japanese user expect to find both occurrences when entering one of them?
The original motivation for the efforts that resulted in Han unification was to help with library and bibliography management (some of these efforts were by non-CJK speakers). One of the original design goals of Unicode was to be able to represent all of the characters in existing character sets uniquely (so two distinct characters in some charset requires two distinct characters in Unicode), and another design goal was to be able to facilitate conversion between different character sets representing the same script. This dovetailed nicely with the existing efforts to unify CJK scripts for bibliographies, hence Han unification.
I guess the accusations of Unicode being somewhat centered on western languages do have a point.
But this is "off-band" information and it kind of defeats the purpose of unicode. Moreover it is extremely annoying in practice: imagine that you write a text (e.g., a comment on HN) where you want to explain the character differences between japanese and chinese. How do you get to do that? There are no "language selector characters" in unicode!
EDIT: just to try, it seems that it works 平仮名 ひらがな 漢字 汉字 한자
The Variation Selectors Unicode block¹ has three variation selectors designated for this purpose:
• U+FE00 VARIATION SELECTOR-1
• U+FE01 VARIATION SELECTOR-2
• U+FE02 VARIATION SELECTOR-3
I assume they work like U+FE0E VARIATION SELECTOR-15 (for 'text presentation' of the preceding character) and U+FE0F VARIATION SELECTOR-16 (for 'emoji presentation' of the preceding character). You can see examples of that in action here².
――――――
¹ — https://en.wikipedia.org/wiki/Variation_Selectors_%28Unicode...
² — https://apple.stackexchange.com/questions/180400/how-to-turn...
there aren’t many fonts that cover both Japanese and Chinese, much less to say beautifully, and as a user I’d say ideally the relevant font should be used in respective languages.
If on the other hand you count the languages that use writing systems with an upper/lower case distinction, then most use Latin, a much smaller set use Cyrillic; and the rest of the writing systems are used by one or two languages each, with the notable exception of the Arabic script.
So most scripts lack an upper/lower case distinction, but probably most languages use a script that does have such a distinction.
If you want case insensitivity, and you also want internationalization, you'd better hope you have a good library that handles the edge cases, or you'll get a bunch of errors. Case-sensitive is far easier to program.
Case-insensitive search/comparison requires a temporary mapping, not a permanent transformation; the German case is easily handled in Unicode's CaseFolding.txt by just mapping all three of them either to ss or to ß (depending on the implementer, if he prefers a length-invariant mapping or not).
Position-dependent? I read about it, but the Unicode case folding algorithm doesn't support it, so I imagine it's not considered useful for case-insensitive comparison
You will probably do want a good library when dealing with Unicode, but for this case thing it actually doesn't seem to be that complex to implement by hand...
I don't doubt case-sensitive is far easier to program , but you usually program for some user's sake, not for your own pleasure :)
And in most cases a normal user expects case-insensitive search
More precisely, I would probably agree that the concept of case is not so useful and we'd probably live well if it were only a graphical attribute (or not even that), without any uppercase (or lowercase) character in the character sets, but since the characters do exist as of now, are spread everywhere in text and in almost any case when a user of a bicameral * script (or at least the Latin one) wants to search normal text he wants a case-insensitive search, your software would better be able to perform it, and usually by default.
By the way, I refreshed my Unicode and it doesn't look like Unicode case-insensitive is that difficult, it would seem that you basically only have to perform the mappings listed in CaseFolding.txt (+ maybe the normalization steps).
* I'm ashamed to admit that I either just learned the term or had completely forgot about it
As long as you cannot compare strings, you cannot search for them.
As long as identifiers are treated as binary (e.g filesystem paths, names, ...), there are tons of security holes in the most basic things, like kernel drivers. Adding unicode support to any product does not make much sense then. Rather restrict it to Latin-1 or the current locale to be on the safe side. Nobody knows the security recommendation for identifiers.
(as in, whether the primitive of comparing/collating two unicode strings can be used for arbitrary computation)
In this article, unusually, text is difficult because of naive expectations, not because of incompetence. For example, the treatment of case-insensitive comparisons is quite good, but the author thinks that counting "characters" should be simple and well-defined, that conversion between uppercase and lowercase characters should be reversible, and that that one can "obviously use well supported libraries that solve this problem for you".
Currently, one organization decides what symbols/emoji we can use, and I think that's stifling our expression.
The unicode consortium has been historically inclusive enough to avoid alienating enough people to cause a revolt.
They have defined ranges where they will not assign code points as private use areas, and you can use those for whatever symbols you need, but of course there's no mechanism to resolve disputes over use, and you would need your own method to determine which font was appropriate, and its likely to be challenging to use outside of applications you control.
But I have thought of some mechanisms to declare character sets and character mapping, to determine which font is appropriate, etc. Unicode is a valid choice, but even if you select Unicode as your character set of use, you must specify the language code and the Unicode version. You can also specify more than one mapping, and custom mappings, for example if you are using CSUR to write in Klingon and English, then you can declare both Unicode and CSUR, together with the relevant version numbers.
I thought of a similar mechanism for declaring character sets and character mapping for TAVERN32 (which doesn't exist yet, but it is meant to be an improved text adventure game VM having the advantages of both TAVERN and Glulx). One lump declares the character sets and character mapping, and can include fallbacks if wanted, so that if ASCII mappings are declared, then it can work with any implementation even if they do not know about that character set. The story file might also (optionally) include other lumps with bitmap fonts, so that also allows it to work even if the character set is unknown (as long as it can display graphics, which some implementations may be incapable of). However, in this case, the character mapping is also relevant for compression too, and not only for determining character sets. There is then the possibility that multiple codes will be mapped to the same ASCII character (or sequence of characters in ASCII or any other character set), avoiding the problem of compatibility.
What I want is refer to new symbols through some unique ID, a decentralized way to serve those symbols, including all relevant information (such as what those symbols mean, what they are based on, what glyphs are preferred/available, how the use of these symbols evolved over time, references to related symbols, etc. etc.).
If I want to invent a symbol for a Coke can, a link to an external website [1], a new mathematical operator, or even Covid19, I want to be able to do it now, not wait for Unicode to stamp the proposal.
I'm not sure where it comes from and what's come of it; seeing as the next sentence is "server could track usage", I have the feeling it's from the editor from Google... ;) (Mark Davis)
Current proposal to support pretty much exactly that, that is a generic Wikidata identifier (for emojis).
I'm not sure how I feel about that, on one hand I would like to have a widespread system to refer to stuff in an ontology, on the other hand it would probably make anything using plain text download stuff from the internet, and maybe even require a connection in simplicistic implementations...
Also, I kinda hate emojis, so... :)
PostScript allows characters to have names instead of only numbers (you can change the assignment of numbers to each name), or you can use CID keying which means given a character set name, that decides what each 16-bit number corresponds to. Adobe said you will have to register the character set name, but I think that you can use URIs (or UUIDs, which are a special case of URIs). You could also use UUIDs as XUIDs, by using 36#UUID as the organization number, and then the next four numbers make up the UUID.
I am working on a character set actually, but it isn't really decentralized nor is it meant to replace Unicode in all of its uses; it is meant only for a specific use, which is grid-based displays (such as terminal emulators). There is a 8-bit mapping, which can be used to encode text, and there is a 16-bit mapping, which can be used for fonts and for tables within terminal emulation software to convert character codes from other character sets. Additionally, it has the property that both the 8-bit and 16-bit mappings allow easily figuring out the width of a string, without needing any tables, without having any ambiguity, and without the possibility to be changed in future (you can actually just add together the widths of the bytes, which are determined using a simple rule; control codes have undefined widths). The 8-bit mapping is also compatible with principle of extended ASCII (like UTF-8 is, although the format is different from UTF-8).
I have also seen someone else on IRC also mentioning making up such a character set for grid-based displays, although theirs was simpler than mine, not having any non-ASCII single width characters at all. I consider that drawback unacceptable, so I made one which is almost as simple, but allows non-ASCII single width characters.
One thing that Unicode is good for though is searching collections of documents written in many languages. However, Unicode has many features which are excessive, unnecessary, or problematic, for that purpose, too.
Another alternative I have seen once on IRC is Duocode, where each character code has two halfs, being the language code and the glyph code. For the purpose of searching documents in many languages, this Duocode idea might even be better than Unicode (especially if many of the messy features of Unicode are avoided).
And, for Chinese writing, there is Cangjie encoding. (I think Cangjie is mostly used as a input method, although it could also be used as a character set for Chinese writing.)
I also don't need emoji, I think.
All defined Unicode codepoints do have names. "Mathematical Monospace Capital C" is codepoint U+1D672. Using character names as an encoding is inefficient but valid, you can do so in e.g. Perl: $foo = "\N{MATHEMATICAL MONOSPACE CAPITAL C}";
Btw., Perl is the one language I would point out for really excellent Unicode support, I know of none that comes even close.
But I agree it isn't really that good; having a character set name and then the numbers, would be better, I think. PostScript supports that too, though.
There are admittedly a few oddities in Unicode (like the treatment of some characters composed of others in Devanagari, IIRC), but they are blessedly rare. What's complicated is writing systems. Have a look at the Burmese script, or contextual variants in Arabic script, and you'll begin to understand why Unicode is complicated.
Well, the whole emoji idea of encoding images using font codepoints is silly.
Alternative would be just use crypto-hashes of SVG / PNG images (perhaps encoded by some unicode codepoints), which could be resolved by some image repositories. There could be multiple repositories and software could use many of them.
But if there were a "decentralized" version of unicode (the lower case 'u' here is intentional), I'm afraid it would be the wild west. In fact I can recall a time in the early 2000s where a group I was with was trying to deal with Hindi (Devanagari) electronic text. It seemed like every website had its own encoding; no one used the ISCII standard, and only a couple websites (none in India) used Unicode. Deciphering the encodings was made even more difficult by the fact that some of them were actually stroke encodings, not character encodings--as if the letter 'd' were made of the character 'c' plus the character 'l'. Humans had to use the website's font in order to read the page, and of course it was hopeless for a computer to read it without a hand-built encoding converter. It was awful.