Show HN: unicode.style
unicode.styleScreen readers donโt do very well with this, so please only use it for novelty purposes. Otherwise you will unnecessarily be locking people out from what you write.
To be fair, combining some of the HN comments:
You'd hope a screen reader would have more effort put into it than a 3 second read of a HN thread?$ python Python 3.7.0 (default, Jul 22 2018, 21:11:34) [Clang 9.1.0 (clang-902.0.39.2)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import unicodedata as ud >>> ud.normalize('NFKD', '''It's a kinda ascii-art thing that ๐ฉ๐ข๐ฑ๐ฐ ๐ถ๐ฌ๐ฒ ๐๐ซ๐ฐ๐ด๐ข๐ฏ ๐ฅ๐ซ ๐ ๐ฌ๐ช๐ช๐ข๐ซ๐ฑ๐ฐ ๐๐ฉ๐ฉ ๐ฃ๐๐ซ๐ ๐ถ ๐ฉ๐ฆ๐จ๐ข ๐ฑ๐ฅ๐ฆ๐ฐ. ๐๐ฃ ๐๐๐๐ ๐ฅ๐๐๐ค ๐๐ ๐ช๐ ๐ฆ ๐จ๐๐๐ฅ ๐๐๐ค๐ค ๐๐ ๐ฅ๐๐๐ ๐๐ ๐ฃ๐ ๐ ๐ฆ๐ฅ๐๐๐๐. ... ... ๐ธ๐๐'๐ ๐๐๐๐๐๐๐ ๐๐๐๐๐?''') "It's a kinda ascii-art thing that lets you answer hn comments all fancy like this. Or like this if you want less gothic more outline.\n\nIsn't unicode great?" >>>I often wonder how many of the people who bring up the capabilities of screen readers are actually familiar with screen readers. (I'm admittedly not at all familiar with screen readers or their capabilities).
As a counterpoint, selecting that text and choosing โspeakโ from the pop up menu doesnโt speak that text on iOS.
VoiceOver on iOS doesnโt speak it, either.
> Screen readers don't do very well with this
Badly-implemented screen readers don't do very well with this. The Unicode Standard provides a Normalization Form for Compatibility Decomposition (NFKD / NFKC) that screen readers definitely should adopt in their Unicode implementation [1].
Well, look forward to spammers using this to bypass the spam filters...
Also using similar unicode characters in your username for nefarious spoofing attacks or worse -- https://labs.spotify.com/2013/06/18/creative-usernames/
This is called a Homoglyph attack.
If you accept unicode for strings that should be "unique" (eg username), there are various normalization schemes that basically convert equivalent-ish looking characters into a consistent hash.
I have no doubt spam filters use this.
I'm still waiting for the .corn TLD...
Followed by spam filters keying in on use of such alternative/modifier characters and marking them as spam. Better check your spam folder if you get a lot of e-mails with mathematical formulas.
Don't they already do that? I can clearly remember subjects that mixed latin, cyrillic, greek and some more exotic scripts to do just that.
That really has to get fixed though.
It doesn't and shouldn't.
The whole point of having Mathematical Alphanumeric Symbols as separate unicode code points, rather than just using normal latin characters with style markup, is so they can be used when the different letters have semantically different meanings -- in particular in maths when ๐น and ๐ can be in the same formula, representing different concepts. They're not a replacement for style markup.
In other words, they're different characters specifically so that screen readers can know to read them out loud differently!
Trying to 'fix' screenreaders by having them read anything that them as if they were normal latin characters, to accommodate people who like using the Mathematical Symbols block for fun in places which only allow plain text, would completely defeat the actual purpose of them.
How do screen readers handle other aspects of mathematical equations? For example, if I have an equation like "A equals B to the C", how do I represent this such that a screen reader will say it correctly? As far as I can tell, I can't.
I see the FAQ you linked states that I'm supposed to use markup for this. Unfortunately, that means the screen reader needs to understand math markup to work correctly. If that's the case, it seems like we could just include other concerns like Bold X vs X in the math markup as well.
> How do screen readers handle other aspects of mathematical equations? For example, if I have an equation like "A equals B to the C", how do I represent this such that a screen reader will say it correctly?
This was one of the problems that MathML was built to solve, see https://accessibility.princeton.edu/blogs/mathml-accessible-...
Am I confused as to what unicode.style is doing? Oh, yes I am. It's using U+1D400 MATHEMATICAL BOLD CAPITAL A and such. I see. Ok, thanks for setting me straight!
Itโs really not a screenreaderโs job to guess what a character might be being pressed into service to represent in a given scenario, and to try to work out when thatโs inappropriate and it should be using the original specified meaning.
Well, it kind of is. In my mind, a screen reader should read anything that a healthy human can. Ideally even text in images and any sort of weirdness.
Then again different healthy humans read texts differently. There's no such thing as a canonical reading and any reading bring in prior semantics.
There was a sign posted in the break room of a lab I used to work at. It read, "<long complex equation> is easy for you to read, but not for everyone. Volunteer to read for the blind." It was a good double whammy.
Speaking of styling things for novelty, there's also this
I'm having trouble understanding what this does. Apparently there's a popover when you select the text you typed. I had to go to https://github.com/ekmartin/unicode-style to figure this out.
It's a kinda ascii-art thing that ๐ฉ๐ข๐ฑ๐ฐ ๐ถ๐ฌ๐ฒ ๐๐ซ๐ฐ๐ด๐ข๐ฏ ๐ฅ๐ซ ๐ ๐ฌ๐ช๐ช๐ข๐ซ๐ฑ๐ฐ ๐๐ฉ๐ฉ ๐ฃ๐๐ซ๐ ๐ถ ๐ฉ๐ฆ๐จ๐ข ๐ฑ๐ฅ๐ฆ๐ฐ. ๐๐ฃ ๐๐๐๐ ๐ฅ๐๐๐ค ๐๐ ๐ช๐ ๐ฆ ๐จ๐๐๐ฅ ๐๐๐ค๐ค ๐๐ ๐ฅ๐๐๐ ๐๐ ๐ฃ๐ ๐ ๐ฆ๐ฅ๐๐๐๐.
๐ธ๐๐'๐ ๐๐๐๐๐๐๐ ๐๐๐๐๐?
Yup, appears relatively hard to use via Chrome mobile with Gboard. You just about can, but most words get swallowed and the site popover is in the same place as the Android text assistance popover
๐๐ฌ๐ฑ๐ฅ ๐จ๐ซ๐ฌ๐ด ๐ฅ๐ฌ๐ด ๐ฑ๐ฌ ๐ฒ๐ฐ๐ข ๐ฐ๐๐ฆ๐ก ๐๐ฒ๐ฑ๐ฌ๐ช๐๐ฑ๐ข๐ก ๐ ๐ฌ๐ช๐ญ๐ฒ๐ฑ๐ข๐ฏ ๐ฌ๐ญ๐ข๐ฏ๐๐ฑ๐ฆ๐ฌ๐ซ?
Also seems to support the "standard" shortcuts for formatting (Ctrl+I/U/B, perhaps others), but yeah, the introduction might be lacking.
I have been using https://yaytext.com for quite a while. Only for novelty purposes, of course.
Underlines aฬฒrฬฒฬฒฬฒeฬฒฬฒฬฒฬฒฬฒฬฒฬฒ ฬฒฬฒฬฒฬฒฬฒฬฒฬฒaฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒ ฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒlฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒฬฒittle nesty when re-selecting already underlined characters from the left
This seems like a major source of security issues. How can i protect myself from it?
Am i supposed to normalize ALL untrusted user input or will that break normal text in some language i'm not familiar with? Or only normalize things that are supposed to be unique, like urls, usernames and other identifiers?
I would make it more clear what the app does and that you should highlight text to format it.
I discovered that by accident.
On iOS, the selection popover interferes with the one you designed.
Good point. Iโm planning on implementing a static (always-enabled) toolbar for mobile devices โ hopefully thatโll make it better.
Maybe if your options appeared below the selection rather than above they wouldnโt interfere.
Same on Android.
Very neat utility, though!
On macOS (High Sierra) the Gothic and next font after that (sorry I forgot what the icon was) don't work for capital letters (get a rectangle with some small digits in). The "Courier" font and handwriting style ones work fine.
Doesn't work with accented latin alphabet characters ("รผ๐๐๐ฃ") - is it a fundamental restriction of the styled unicode charset or a mapping issue? Seems like it should be supported but would need a transition from precomposed characters to the equivalent combination of letter + diacritic.
It's not a fundamental restriction in the character set; "๐ฆฬ๐๐๐ฃ" is valid.
It does not work with numbers either, though that can be worked around a little bit by using the number-in-circle variants.
What about "strikethrough" and "slashthrough"?[0,1,2]
P.S.: It's look like you reinvent YayText[3] website ;-)
[0] http://adamvarga.com/strike/
[1] https://yaytext.com/strike/
https://github.com/ekmartin/unicode-style/blob/master/src/tr...
I learned something new today, thanks!
Android Firefox is just showing me black boxes for those Unicode ranges, so this definitely can't be very effectively used everywhere (I haven't tried yet, but I'm guessing some native messaging apps may have similar issues).
You should keep the toolbar on the screen.
Neat idea but completely unusable on Firefox mobile due to the context menu that pops up whenever text is selected and obscures the site's menu that does the same.
There is something about rendering these unicode code points that seems to make Firefox jank more than usual (when scrolling this page up and down). Are rendering these code points especially costly for some reason?
People might find Unicode Text Converter useful as well.
๐ฅ๐ฆ ๐ฅ๐๐๐ฃ๐ ๐ฏ๐ป๐ฒ๐ฎ๐ท๐ญ
It was not initially ๐ฎ๐ฝ๐ฝ๐ฎ๐ฟ๐ฒ๐ป๐ to me that I could ๐ด๐ต๐บ๐ญ๐ฆ things that I typed.
Not clear what this does? Also, copy button doesnโt work on iOS.
It lets you ๐ฏ๐ผ๐น๐ฑ or ๐ค๐ฅ๐ช๐๐ stuff in unicode, so plain-text places (like Hacker News) can get formatting.
HN supports italics it's not entirely plain-text
๐พ๐๐ ๐๐ ๐๐๐ ๐๐๐๐๐๐๐ ๐๐ ๐ท๐ฝ ๐๐๐๐๐ข ๐๐ ๐ ๐๐๐ ๐๐๐๐๐๐๐๐๐๐ ๐๐๐ ๐๐๐๐ ๐๐๐๐๐๐๐๐๐๐ ๐๐ ๐๐๐๐ ๐ ๐๐๐๐๐๐๐๐๐๐, ๐๐๐๐ ๐๐๐๐๐๐๐ ๐๐๐๐ ๐๐๐ ๐๐ ๐๐๐๐๐ข ๐ ๐๐๐ ๐๐ ๐๐๐๐๐๐๐๐๐๐๐ ๐๐๐ ๐๐๐ ๐๐๐๐๐๐๐ ๐๐ ๐๐๐๐๐๐ ๐๐๐๐๐. ๐ธ ๐๐๐๐๐ ๐๐๐ ๐๐๐๐ ๐๐๐๐๐ ๐ ๐ ๐๐๐๐๐๐๐๐๐ ๐๐๐ ๐๐๐๐ ๐๐๐๐๐๐๐๐๐๐. ๐ต๐๐ก๐๐ ๐ ๐๐๐๐ ๐๐๐ก๐ ๐ ๐๐๐๐๐๐ ๐๐๐ ๐๐๐๐๐ฃ๐๐๐๐๐ ๐๐๐๐๐๐๐๐๐ ๐๐ ๐๐๐๐๐๐ ๐๐๐๐๐๐๐.
Or perhaps HN should fix some properties formatting after all these years? Code gets posted here pretty regularly after all...
it's a wysiwyg-style editor for bold / italics / etc where it replaces the selected range with the unicode bold/etc characters.
type some text, then select it. that'll give you a format editor.
A little faded gray hint could have helped :)
Nice work. +1 I would ๐น๐ผ๐๐ฒ to see this as a chrome plugin.
Is it just me, or does the BB style render the most interesting characters as rectangles? (Chrome on OS X)
๐ธ ๐น ๐บ ๐ป ๐ผ ๐ฝ ๐พ ๐ฟ ๐ ๐ ๐ ๐ ๐ ๐ ๐ ๐ ๐ ๐ ๐ ๐ ๐ ๐ ๐ ๐ ๐ ๐
This is entertaining but it's completely broken on Chrome mobile in a way I've never seen before.
This would be great as an Emacs extension. Is there something like this?
๐ฒ๐ซ๐ฆ๐ ๐ฌ๐ก๐ข.๐ฐ๐ฑ๐ถ๐ฉ๐ข
๐๐ฌ๐ฏ๐ช๐๐ฑ ๐ฑ๐ข๐ต๐ฑ ๐ฒ๐ฐ๐ฆ๐ซ๐ค ๐ฒ๐ซ๐ฆ๐ ๐ฌ๐ก๐ข ๐ ๐ฅ๐๐ฏ๐๐ ๐ฑ๐ข๐ฏ๐ฐ. ๐๐๐ฐ๐ฑ๐ข ๐๐ซ๐ถ๐ด๐ฅ๐ข๐ฏ๐ข ๐ฑ๐ฅ๐๐ฑ ๐๐ ๐ ๐ข๐ญ๐ฑ๐ฐ ๐ญ๐ฉ๐๐ฆ๐ซ ๐ฑ๐ข๐ต๐ฑ.
Neat. Suggestion: maybe donโt โunderlineโ characters such as y or g
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.
> 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.
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?
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.
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 '.
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.
> 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...
> 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.