25 comments

[ 2.5 ms ] story [ 36.7 ms ] thread
Now make a readable version where the braille symbols are converted into their latin alphabet equivalents.
The Braille symbols are used as subpixels, not for their meaning. It’s a convenient way to basically have 8 pixels (2x4) per display character.
I am fully aware. Please reinterpret my statement knowing now that I know that.
Ah, I thought your original comment was referring to using the corresponding letters for the Braille (semantically), but now I guess you're probably unable to see it because your terminal doesn't have the Braille fonts (or doesn't have UTF-8 support?). I guess it would be possible to hack the code (it's just JS running under Node) to change the output character set; the challenge (as usual with ASCII) is to pick a character set that looks good.

But honestly, it's not as if using 7-bit ASCII will make it any more "readable"; more compatible, possibly, but the use of Braille subpixels definitely makes the map look visually nicer.

> I thought your original comment was referring to using the corresponding letters for the Braille (semantically)

It was. You're overthinking this. I want to see what the braille reads like.

That's a strange request, along the lines of wanting to know what your mp3s spell if you just converted the encoded data into whatever characters the drama happens to encode.
Ah, well, your original comment was a little unclear there, so apologies for the confusion.

Unfortunately most of the characters won’t map onto any Latin letter. Typical English Braille only uses the top 6 dots - but as a display character, this program uses all 8 dots. I’m not even sure which Braille dialects use all eight dots. As another commenter hinted at, it’s a bit strange to ask what the semantic meaning of graphical display characters are - a bit like reading out the characters in a binary file which happen to correspond to ASCII values. (Like, what might happen if you open a binary file in a text editor).

This is a total tangent, but it might be interesting to scrape map output for meaningful words formed by the braille characters.

Or we just leave that to enterprising conspiracy theorists, as a new kind of "backwards masking".

Shameless plug for: `ssh brow.sh -t https://maps.google.com`
It's too bad that text labels don't show up correctly (because they're rendered to pixels like the map), but otherwise, wow that's impressive. It works like a charm on XTerm on Mac. (It doesn't work with Terminal.app, but that's because Terminal doesn't support 24-bit colour commands IIRC, so I am not surprised).
(comment deleted)
Maybe use the unicode rendering engine from chafa to improve the output quality: https://hpjansson.org/chafa/ https://github.com/hpjansson/chafa
The current version seems to have trouble with text direction when rendering RTL scripts; if you look at the Wikipedia homepage, the links for the Arabic and Hebrew Wikipedias appear with the names of the languages written LTR rather than RTL. Maybe a different Unicode rendering method would also help address this problem.
This is impossible to fix on the terminal. But you can render it correctly with bidiv or fribidi. Yet, this breaks copying.
Asciinema has a hilarious full-screen mode, at least in FF: it's a fully black screen with a small video in the center.

----

Also, I wonder if terminal lovers should maybe lobby for a set of Unicode symbols with more ‘pixels’ than the Braille 2×8.

Considering that terminals can display images just fine you'll have a hard time convincing Unicode that you need arbitrary pixel sets because somehow images are plain text (emoji had prior usage in plain text and they have a lot more semantic meaning per character than just some pixels).
Support for images is spotty and inconsistent, whereas ‘display unicode characters in a given font’ is the central thing that terminals do these days.
Cool project. Kudos for offering an example via telnet!