3 ms·

I wonder actually. Google seems to understand these, you can search with them. I wouldn't be surprised if screen readers understand these symbols. They're origi

I wonder actually. Google seems to understand these, you can search with them. I wouldn't be surprised if screen readers understand these symbols. They're originally for Mathematics, and I'm sure there's plenty of blind mathematicians.

X-Istence 8y ago
Some of them are outside the mathematical range, that just happened to be the one I picked. Google has a lot of resources to do normalization, when IDNA in the URL bar became common they and other browser manufacturers had to put resources behind similar looking glyph attacks to make sure that you were actually on google.com and not on some site that was using a homoglyph attack. https://blog.malwarebytes.com/101/2017/10/out-of-character-homograph-attacks-explained/ https://blog.malwarebytes.com/101/2017/10/out-of-character-h... This may explain why Google is able to discern these use cases.
- deleted 8y ago
  [deleted]
- floil 8y ago
  In chromium, the glyph attack defense works by normalizing to a "confusability skeleton" -- the ICU library actually does the normalization. Even within latin-1 this does some mangling: m gets normalized to rn, w to vv, etc. The query rewriting is a different problem, but it's possible it uses the confusables list as an input.
snek 8y ago
blind mathematicians don't write english to communicate in these unicode blocks... These blocks don't exist to be used for writing words in the english language.
- shadowfaxRodeo 8y ago
  Yes, I just mean to say, if you were creating a screen reader, it wouldn't be that hard to take this sort of thing into account. So, maybe they do. Either way, I'll add a little warning to the site.
  - sbarre 8y ago
    Ah yes.. The old "if you were creating <thing author doesn't know much about>, it wouldn't be that hard to take this sort of thing into account"
    - shadowfaxRodeo 8y ago
      Well, we live in an age of wonder, I heard they landed a man on the moon.
  - anoncake 8y ago
    Even if it is not hard to take this thing into account, it is definitely hard to take all the things into account. Adding more things doesn't help.
RickS 8y ago
It's less "can they render them" and more "do they maintain their meaning in alternate renderings". For example, it's common in these to use non-latin characters that visually resemble latin characters. But if you were to try and substitute them literally, either as their actual phonetic sound, or a latin equivalent that is semantically similar but visually different, you risk breaking the meaning. It's a bit like when old manuscripts use letters that look like "s" and "f" in places that seem nonsensical today. In google's case, it's certainly worth it to write a little interpreter that maps the visual meaning to its latin equivalent so you can get better search results.
- deleted 8y ago
  [deleted]
- cmg 8y ago
  >It's less "can they render them" and more "do they maintain their meaning in alternate renderings". I just entered "this is a test" on the site in Safari and enabled VoiceOver. It reads it as "Mathematical Bold Fraktur Small t. Mathematical Bold Fraktur Small h" and so on. Completely broken for those who rely on VoiceOver as a screenreader.
  - snacklesnapp 8y ago
    Just configure it to not pronounce the "Mathematical Bold Franktfur Small" bits
Ajedi32 8y ago
Wow, that's actually pretty neat: https://www.google.com/search?q=site%3Anews.ycombinator.com%2F+Fancy+fonts+you+can+use+almost+anywhere https://www.google.com/search?q=site%3Anews.ycombinator.com%... Anyone know if there are any existing libraries that do this conversion?
- itcmcgrath 8y ago
  Look up Case Folding for how this is done, most languages have libraries to handle it.
- roywiggins 8y ago
  Here's a test page for one. http://minaret.info/test/normalize.msp http://minaret.info/test/normalize.msp
- kevindqc 8y ago
  If you use c#: "𝕙𝕖𝕝𝕝𝕠".Normalize(NormalizationForm.FormKC);
- aurelian15 8y ago
  The ICU [1] transliterator does this. Here is an example showing how to use it: icu::ErrorCode status; auto t = icu::Transliterator::createInstance("Any-Latin; NFKD", UTRANS_FORWARD, status); t->transliterate("unicode string"); [1] http://site.icu-project.org/ http://site.icu-project.org/
reaperducer 8y ago
I wouldn't be surprised if screen readers understand these symbols. I develop web sites with screen readers in mind, and I would be very surprised if they could handle this sort of thing consistently. Google spent billions of dollars learning how to search and interpret the web. Screen reading companies don't have that kind of scratch. Also, it's important to remember that screen readers are about more than just the blind. There are screen readers that help people learn a new language, or translate text into simplified forms for people with low education, or low attention (think of the Mac's built-in text summarizing service). For people who have a hard time reading custom fonts because of limited sight, or limited attention, they often override custom CSS fonts with something easier to read. This sort of thing will make the page unusable.
- nmstoker 8y ago
  I'm not trying to suggest screen reading is easy, but the billions of dollars Google invest are not comparable here as they obviously do a huge range of things and the reader tools need to do a much narrower range. This came up at Halloween with all those pleas not to post tweets heavy with emoji due to the issues with screen readers. I get the concern, and I'd typically do my best to be inclusive with personal content and compliant with accessibility on professional content, but there is a balance to be struck - we don't need a Procrustean restriction on what are now reasonably established forms of communication, what we need is for screen reader efforts to step up and work in these cases. It may seem a challenge (especially for legacy coded readers) but other posters already linked to basic solutions that can help on the fonts and this isn't beyond the wit of human ingenuity. This is an opportunity.
  - reaperducer 8y ago
    I'm not saying that we need to prohibit anyone from using crazy fonts. I'm merely responding to a postulation that screen readers could probably handle the text. My response, from experience, is that they probably can't, and most people misunderstand the myriad of uses for screen reading technology. Odd fonts like this have a place. For example, I don't expect any screen reader ever to be able to interpret a PETSCII drawing.
babuskov 8y ago
Interesting. This made me wonder about small caps. Aᴘᴘᴀʀᴇɴᴛʟʏ Gᴏᴏɢʟᴇ ᴅᴏᴇsɴ'ᴛ sᴜᴘᴘᴏʀᴛ ᴛʜᴏsᴇ.
pavelrub 8y ago
I tested the ones with circles and squares, and Google definitely doesn't understand them.
nothrabannosir 8y ago
This is called unicode normalisation, specifically NKFD form. You can do it in two lines of Python. This was covered last time a similar website came up (plagiarising myself): https://news.ycombinator.com/item?id=17752680 https://news.ycombinator.com/item?id=17752680 unicode normalisation: http://unicode.org/reports/tr15/ http://unicode.org/reports/tr15/ Nobody in that thread tried it on an actual screen reader then, either. Someone did mention that iOS got well confused by it, so there's one data point.

X-Istence 8y ago

Some of them are outside the mathematical range, that just happened to be the one I picked. Google has a lot of resources to do normalization, when IDNA in the URL bar became common they and other browser manufacturers had to put resources behind similar looking glyph attacks to make sure that you were actually on google.com and not on some site that was using a homoglyph attack. https://blog.malwarebytes.com/101/2017/10/out-of-character-homograph-attacks-explained/ https://blog.malwarebytes.com/101/2017/10/out-of-character-h... This may explain why Google is able to discern these use cases.

deleted 8y ago
[deleted]
floil 8y ago
In chromium, the glyph attack defense works by normalizing to a "confusability skeleton" -- the ICU library actually does the normalization. Even within latin-1 this does some mangling: m gets normalized to rn, w to vv, etc. The query rewriting is a different problem, but it's possible it uses the confusables list as an input.

snek 8y ago

blind mathematicians don't write english to communicate in these unicode blocks... These blocks don't exist to be used for writing words in the english language.

shadowfaxRodeo 8y ago
Yes, I just mean to say, if you were creating a screen reader, it wouldn't be that hard to take this sort of thing into account. So, maybe they do. Either way, I'll add a little warning to the site.
- sbarre 8y ago
  Ah yes.. The old "if you were creating <thing author doesn't know much about>, it wouldn't be that hard to take this sort of thing into account"
  - shadowfaxRodeo 8y ago
    Well, we live in an age of wonder, I heard they landed a man on the moon.
- anoncake 8y ago
  Even if it is not hard to take this thing into account, it is definitely hard to take all the things into account. Adding more things doesn't help.

RickS 8y ago

It's less "can they render them" and more "do they maintain their meaning in alternate renderings". For example, it's common in these to use non-latin characters that visually resemble latin characters. But if you were to try and substitute them literally, either as their actual phonetic sound, or a latin equivalent that is semantically similar but visually different, you risk breaking the meaning. It's a bit like when old manuscripts use letters that look like "s" and "f" in places that seem nonsensical today. In google's case, it's certainly worth it to write a little interpreter that maps the visual meaning to its latin equivalent so you can get better search results.

deleted 8y ago
[deleted]
cmg 8y ago
>It's less "can they render them" and more "do they maintain their meaning in alternate renderings". I just entered "this is a test" on the site in Safari and enabled VoiceOver. It reads it as "Mathematical Bold Fraktur Small t. Mathematical Bold Fraktur Small h" and so on. Completely broken for those who rely on VoiceOver as a screenreader.
- snacklesnapp 8y ago
  Just configure it to not pronounce the "Mathematical Bold Franktfur Small" bits

Ajedi32 8y ago

Wow, that's actually pretty neat: https://www.google.com/search?q=site%3Anews.ycombinator.com%2F+Fancy+fonts+you+can+use+almost+anywhere https://www.google.com/search?q=site%3Anews.ycombinator.com%... Anyone know if there are any existing libraries that do this conversion?

itcmcgrath 8y ago
Look up Case Folding for how this is done, most languages have libraries to handle it.
roywiggins 8y ago
Here's a test page for one. http://minaret.info/test/normalize.msp http://minaret.info/test/normalize.msp
kevindqc 8y ago
If you use c#: "𝕙𝕖𝕝𝕝𝕠".Normalize(NormalizationForm.FormKC);
aurelian15 8y ago
The ICU [1] transliterator does this. Here is an example showing how to use it: icu::ErrorCode status; auto t = icu::Transliterator::createInstance("Any-Latin; NFKD", UTRANS_FORWARD, status); t->transliterate("unicode string"); [1] http://site.icu-project.org/ http://site.icu-project.org/

reaperducer 8y ago

I wouldn't be surprised if screen readers understand these symbols. I develop web sites with screen readers in mind, and I would be very surprised if they could handle this sort of thing consistently. Google spent billions of dollars learning how to search and interpret the web. Screen reading companies don't have that kind of scratch. Also, it's important to remember that screen readers are about more than just the blind. There are screen readers that help people learn a new language, or translate text into simplified forms for people with low education, or low attention (think of the Mac's built-in text summarizing service). For people who have a hard time reading custom fonts because of limited sight, or limited attention, they often override custom CSS fonts with something easier to read. This sort of thing will make the page unusable.

nmstoker 8y ago
I'm not trying to suggest screen reading is easy, but the billions of dollars Google invest are not comparable here as they obviously do a huge range of things and the reader tools need to do a much narrower range. This came up at Halloween with all those pleas not to post tweets heavy with emoji due to the issues with screen readers. I get the concern, and I'd typically do my best to be inclusive with personal content and compliant with accessibility on professional content, but there is a balance to be struck - we don't need a Procrustean restriction on what are now reasonably established forms of communication, what we need is for screen reader efforts to step up and work in these cases. It may seem a challenge (especially for legacy coded readers) but other posters already linked to basic solutions that can help on the fonts and this isn't beyond the wit of human ingenuity. This is an opportunity.
- reaperducer 8y ago
  I'm not saying that we need to prohibit anyone from using crazy fonts. I'm merely responding to a postulation that screen readers could probably handle the text. My response, from experience, is that they probably can't, and most people misunderstand the myriad of uses for screen reading technology. Odd fonts like this have a place. For example, I don't expect any screen reader ever to be able to interpret a PETSCII drawing.

babuskov 8y ago

Interesting. This made me wonder about small caps. Aᴘᴘᴀʀᴇɴᴛʟʏ Gᴏᴏɢʟᴇ ᴅᴏᴇsɴ'ᴛ sᴜᴘᴘᴏʀᴛ ᴛʜᴏsᴇ.

pavelrub 8y ago

I tested the ones with circles and squares, and Google definitely doesn't understand them.

nothrabannosir 8y ago

This is called unicode normalisation, specifically NKFD form. You can do it in two lines of Python. This was covered last time a similar website came up (plagiarising myself): https://news.ycombinator.com/item?id=17752680 https://news.ycombinator.com/item?id=17752680 unicode normalisation: http://unicode.org/reports/tr15/ http://unicode.org/reports/tr15/ Nobody in that thread tried it on an actual screen reader then, either. Someone did mention that iOS got well confused by it, so there's one data point.