[jancsika]

This reveals all kinds of bugs in current software.

For example, if I use the tool to make a url italic, then pasting that url into Chrome's url bar gives me back a bunch of unicode rectangles.

But that's not what I wanted. I wanted Chrome's url bar to interpret those unicode code points as an italic version of the actual unicode code points I want. Chrome should add a check for edge cases like these and add branches to map the string to the corresponding non-styled code points automatically.

Someone needs to send lots of bug reports to all the relevant pieces of software that currently have this bug. Firefox, Chromium, probably Edge, Webkit. Those are just the browsers, but I'm sure there are more. I'm not actually sure about Firefox tbh, but maybe just send the bug report first and see if it gets accepted to find out.

Ooh, here's another one-- if you paste some unicode.style'd text into LibreOffice does it convert it to the "normal" code points and add the relevant styling? If not, it should, otherwise it's broken.

Actually, I just realized another issue. If I type something in the url bar that is styled with unicode.style, then there is no way for Chrome to know whether I want it displayed styled or not.

For example, maybe I'm pasting it there temporarily so that I can copy/paste it later in a Tweet. In that case I probably want to keep the current styling for the tweet.

So Chrome should map to the normalized unicode code points (just in case I'm typing a url or want to instantiate a search), but still display the styled version. Then when I copy it again, it should put the unicode.style version into the buffer. And the app which receives the pasted buffer should receive the unicode.style code points. And of course that app should also normalize it underneath while retaining the styled display for the same reasons.

To deal with this complexity, there should probably be a standardized way for all apps to deal with styled text.

Please help by testing every app and filing relevant bug reports.

[SEMW]

> But that's not what I wanted. I wanted Chrome's url bar to interpret those unicode code points as an italic version of the actual unicode code points I want. Chrome should add a check for edge cases like these and add branches to map the string to the corresponding non-styled code points automatically.

No, it shouldn't. They are semantically different code points. The _whole point_ is that they are semantically different code points (they're from the Mathematical Alphanumeric Symbols block, the purpose of which is for e.g. when you have a formula containing 𝘹 and 𝘅 as semantically different characters, where that difference needs to be preserved in copying & pasing, conveyed to screen readers, etc.

> Ooh, here's another one-- if you paste some unicode.style'd text into LibreOffice does it convert it to the "normal" code points and add the relevant styling? If not, it should, otherwise it's broken.

It really, really, really shouldn't, for the same reason as above.

Mathematical symbols are not a replacement for text styles and markup. Trying to make them that will destroy the thing they're actually useful for, the thing they can do that text styling can't do: preserve their semantics when transmitted in plain text (including for accessibility purposes).

This is not styling. It cannot be normalized away. They are semantically different characters.

https://www.unicode.org/faq/ligature_digraph.html#Pf6

[bjt2n3904]

Ugh. This just further poisons me against unicode being a good thing. ASCII or bust.

"ABCD" and "𝓐𝓑𝓒𝓓" are the same thing, but they also aren't. Am I supposed to normalize everything on username creation to prevent people from making duplicates?

[function_seven]

You either have to do that, or restrict usernames to ASCII subset only (and face the wrath of non-Latin alphabet users), or restrict to a whitelist of ranges that only represent alpha characters across all languages (i.e. not math symbols, nor box-drawing, nor emoji, etc.)

i8n is complicated because the diversity of language is itself complicated. I feel your pain, though, don't get me wrong.

[codebje]

Not normalise, just set the rules you want to apply. Internationalised domain names suffer this issue, so cribbing their fix probably would work for you - pick a script, restrict allowable characters to it.

You probably never want to allow unrestricted use of any character set for a username, even ASCII - otherwise I could take the username 'bjt2n3904 '.

[function_seven]

I can't tell if you're being serious or tongue-in-cheek, but I like this comment nonetheless.

Did Unicode ever have any business assigning separate code points for italic versions of latin glyphs? Am I ignorant as to their true purpose?

EDIT: SEMI just answered my second question. Math. Makes sense.

[wgjordan]

> Did Unicode ever have any business assigning separate code points for italic versions of latin glyphs?

Here's the official answer to this question from the Unicode spec [1]:

"Mathematical notation requires a number of Latin and Greek alphabets that initially appear to be mere font variations of one another. For example, the letter H can appear as plain or upright (H), bold (𝐇), italic (𝐻), and script (ℋ). However, in any given document, these characters have distinct, and usually unrelated, mathematical semantics. For example, a normal H represents a different variable from a bold H, etc. If these attributes are dropped in plain text, the distinctions are lost and the meaning of the text is altered."

[1] https://www.unicode.org/versions/Unicode11.0.0/UnicodeStanda...

[jancsika]

> I can't tell if you're being serious or tongue-in-cheek, but I like this comment nonetheless.

Thanks! I started by interpreting the tool as a serious and important feature of putting styling where UIs don't allow it. Then I did a quick stream-of-consciousness advocacy for fitting the feature in all the places where it isn't allowed.

The results are obviously bad, which is reassuring.