Skip to content

Comment on How the Unicode Committee Broke the Apostropheparent

Comments

The complexity of the problem was increased by the necessity of providing migration paths from legacy encodings to Unicode and back again; without such a guarantee, bootstrapping the world into using Unicode would have been a much more difficult proposition, but that constraint also means that many oddities of legacy encodings have had to be preserved in Unicode in order to be able to preserve that round-trip mapping.

While I agree that preserving round-trip integrity was essential for Unicodes success, I'm not sure if the approach taken to achieve that was the best one. I would have preferred that the complexity tradeoff would have been shifted to software converting between Unicode and legacy encodings by having more complex mapping tables and cleaner code point space.

I also think that Unicode Consortium should have been more aggressive in segregating (and discouraging the general use of) legacy compatibility features/codepoints and the stuff that is actually supposed to be used. My personal pet peeve is precomposed characters.

In a more general note, I sometimes wonder if it would have been beneficial to have separate layers in Unicode and have more focused on providing generic primitives. As a simple example it is mighty convenient that I can type 2³ = 8 in plain text, but arguably it would be even nicer if instead of special 'SUPERSCRIPT THREE' codepoint there would be generic superscript modifier codepoint that could be combined with any character.

Speaking of superscripts, they demonstrate well one aspect that I dislike in Unicode, the way they have absorbed legacy encodings verbatim. The numeric superscripts (e.g. ⁰ ¹ ² ³ ⁴ ⁵ ⁶) happen to have inconsistent look on my machine because the superscripts for 1, 2, and 3 are from Latin1 while the rest are in their own block.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.