3 ms·
Not them, but: - Combining characters, joiners, modifiers, etc. should have been prefix, not suffix/infix, and in blocks by arity. This would have allowed dete
by kps 3y ago
Not them, but:
- Combining characters, joiners, modifiers, etc. should have been prefix, not suffix/infix, and in blocks by arity. This would have allowed detecting incomplete sequences, allowed code to skip combinations without knowing their meaning, and made dead-key input trivial.
- A standard normalized form should have been specified up front.
- Once blocks overflowed, subsequent blocks should have been made large enough that more that one would not be necessary. Unicode has ten different Latin blocks. You've got ‘Kana Extended-B’, ‘Kana Supplement’, ‘Kana Extended-A’ (in that order!), and ‘Small Kana Extension’. (If there's an explanation for ‘Supplement’ vs ‘Extended’ vs ‘Extension’, I've never seen it.)
- Character ordering is inconsistent even within scripts, e.g. ÀÁÂ… àáâ but ĀāĂ㥹.
- Assigning code points for the UTF-16 encoding is ridiculous.
- The contentious cases of CJK unification should have been disambiguated promptly, before use of the originals became entrenched. (I know where to find 2K code points they could have used…)
- They recently changed some characters to have ‘emoji presentation’ by default, meaning that existing text needs to be edited to preserve its original appearance.
- JdeBP 3y agoDead-key input, if done according to ISO 9995, is trivial for exactly that reason. Type all of the combining diacritics, then the base character. * https://jdebp.uk/Softwares/nosh/guide/commands/console-fb-realizer.xml#DEAD-KEYS https://jdebp.uk/Softwares/nosh/guide/commands/console-fb-re...
- cryptonector 3y ago> - Combining characters, joiners, modifiers, etc. should have been prefix, not suffix/infix, and in blocks by arity. This would have allowed detecting incomplete sequences, allowed code to skip combinations without knowing their meaning, and made dead-key input trivial. Yes, this is a very good suggestion. UTF-8 is a multi-byte encoding that is self-synchronizing in either direction. Multi-codepoint characters/glyphs should have been similarly self-synchronizing in either direction. > - A standard normalized form should have been specified up front. There are four. The only reasonable simplifications here would have been to get rid of NFC and NFKC, and maybe NFKD, leaving only NFD, and then maybe also remove all precompositions (but this would have made take-up of Unicode take much longer because it would have required more complexity in implementations earlier). > - Once blocks overflowed, subsequent blocks should have been made large enough that more that one would not be necessary. Unicode has ten different Latin blocks. You've got ‘Kana Extended-B’, ‘Kana Supplement’, ‘Kana Extended-A’ (in that order!), and ‘Small Kana Extension’. That's a function of how allocations were made, especially before UTF-8 and UTF-16, when we were stuck with just the BMP. Well, anyways, we'd need a time machine to get any of these things fixed now. > - Character ordering is inconsistent even within scripts, e.g. ÀÁÂ… àáâ but ĀāĂ㥹. Do you mean codepoint ordering? Hardly matters: the actual ordering will vary by locale anyways. > - Assigning code points for the UTF-16 encoding is ridiculous. That's not a thing. > - The contentious cases of CJK unification should have been disambiguated promptly. (I know where to find 2K code points they could have used…) That would have required getting representatives from those countries to sit down at the UC table sooner. > - They recently changed some characters to have ‘emoji presentation’ by default, meaning that existing text needs to be edited to preserve its original appearance. Blech. Occasionally the UC has to make backwards-incompatible changes, but they should try really hard to keep those to the absolute bare minimum -- zero would be ideal.
- kps 3y ago> That's not a thing. I was referring to U+D800–U+DFFF being reserved just because UTF-16 happens to use 0xD800–0xDFFF for its encoding scheme. Contrast valid code points U+0080–U+00FF, while (most of) 0x80–0xFF are used by UTF-8.
- cryptonector 3y agoYes, surrogate pairs is stupid. We should do away with UTF-16 and liberate the remaining 10 bits of codespace in UTF-8.
- kazinator 3y agoEasier said than done. Programs that don't care about surrogate pairs already use blocks like U+DCxx for their purpose. Liberating the code space for character use would be a poor idea; blessing it for local use would make more sense, but it would just be approving existing practices. I have an implementation in which codes U+DC00 through U+DCFF indicate "this was a bad byte in the original UTF-8". When UTF-8 is generated, these values reproduce the original invalid bytes. Additionally one of those values, U+DC00, is particularly useful since it encodes a null byte that occurred in the UTF-8 stream. While that is not strictly necessary as far as UTF-8 goes, the encoding provides a way to embed the null character in null-terminated strings.
- deleted 3y ago[deleted]