💾 Archived View for rawtext.club › ~sloum › geminilist › 007505.gmi captured on 2021-12-05 at 23:47:19. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2021-11-30)

-=-=-=-=-=-=-

<-- back to the mailing list

A Gemini-style proposal (specifically to the harm of using Unicode characters as if they were formatted ascii)

babiak babiak at disroot.org

Wed Nov 3 10:41:02 GMT 2021

- - - - - - - - - - - - - - - - - - - 

TL;DR : I could bring up any number of straw-man arguments, but those are not useful. The actual argument is as follows. Unicode mathematical characters used as if they were normal characters, just in a fancier font is just plain rude to multiple groups of people, some of whom the gemini specification explicitly recommends accommodating.

Hello, I actually have some knowledge that is relevant here.

...
Regular people don't care whether these were originally for mathematics
or not — they look like bold versions of characters. And a number of
people are already using them as such. (There are even online tools to
help people use them.)
...

This is true. However, as things currently stand, this is not a good thing.

The reason is simple: not everyone looks at screens. Screen readers exist. If I remember correctly, screen readers are actually explicitly mentioned in the gemtext specification, in the context of alt ext for ascii art in preformatted blocs. One could say, the gemini protocol was designed with text-to-speech systems in mind as well as screens. Currently, espeak reads "𝐀, 𝗔" as "letter 1d400, letter 1d5d4". This is worse than putting a clapping hand emoji between every other word, as that at least leaves the words intact.

While it is doubtless possible to write a screen reader that reads these mathematical symbols as if they were not mathematical symbols, for this change to be accepted would require *almost every screen reader on the market* to make this change. Also, what if the character is actually being used in the original context? Say someone wrote down an equation, using these symbols, and didn't note down multiplication? How would a screen reader recognise it as a mathematical context, not formatting?

And even if you are willing to intentionally/neglectfully exclude those with eyesight worse than yours, the fact remains that searching for this text would simply not work on most computers, using the most common algorithms.

Then there's the whole issue of older hardware, with limited or non-existent Unicode support. Expecting everyone to just use a specific set of characters from a relatively modern encoding, when some people are working on getting a functional gemini client working on hardware my father used as a child (slight exaggeration may exist) is just asking for trouble.

If Gemtext can ignore the original semantics of the asterisk, the
back-tick, the pound symbol, the equal symbol, and the greater-than
symbol — then why can't we also do the same with those mathematical
characters?

I personally don't recall the pound symbol having any meaning in gemini, I'll have to look through the spec again. However!

I have a multi-part answer: - tradition: For most of these old symbols, the "original" meaning is no longer used. Even where it is, alternate meanings are common, and well understood. These new symbols still hold their original meaning. - legibility: If someone sees a couple of lines beginning with an asterisk, it is pretty obvious they are bullet points. A screen reader might read them out, in which case they work as audible bullet points, or not, in which case the actual sentences should be entirely understandable. While an individual with a Unicode-supporting font and fully functioning eyes will understand the intended meaning behind these characters, lose any of these, and the entire word is gone, either turned into tofu, or into gibberish.

With no disrespect intended, Babiak.-------------- next part --------------A non-text attachment was scrubbed...Name: OpenPGP_0x659545C9EB192262.ascType: application/pgp-keysSize: 2434 bytesDesc: OpenPGP public keyURL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20211103/27598a31/attachment-0001.bin>-------------- next part --------------A non-text attachment was scrubbed...Name: OpenPGP_signatureType: application/pgp-signatureSize: 665 bytesDesc: OpenPGP digital signatureURL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20211103/27598a31/attachment-0001.sig>