Did anyone even stop to appreciate the irony of using a thing created for blind people to make something that will only ever be useful to people with sight, if at all?
To be the one who takes things too seriously: blind doesn’t mean one can’t see; it just means their vision is bad enough to satisfy some list of conditions. People without sight just happen to fit into that category for some weird reason.
Assuming this is a serious question, I think you will know the answer if you look at how any braille display works. They basically "display" one line of text in braille at a time.
So unless you can appreciate your pixel graphics one printed line at a time, it's unlikely that any blind person will be able to get any benefit from this application.
Existing one-line braille displays don't understand braille unicode anyway. What's to stop a blind person from making a braille display with a greater display area?
I'm not the one who downvoted, and I don't know how many blind people make their own braille displays. It seems unlikely to me. (Not impossible. Another quick search reveals that multi-line braille exist, so it has been done.)
TBH I just did a quick search for braille displays to validate my assumption, and when the first few results came up looking roughly like the one-line display that I expected, I wrote this comment. I'm not an expert in this kind of thing though.
My understanding is that braille displays are quite mechanically complex, as each cell needs to be able to individually raise and lower six pips. An 80-character, single-line terminal display would require 480 tiny actuators.
A full page braille display with 1,000 cells (25 lines of 40 cells) was
developed in 2015 by the Tactisplay Corp.[3] With total 12,000 pixels
configured in 120*100, it can show any BANA compatible braille
graphic page in 8 seconds. This video shows operation of the device.
I reject this idea that a blind person is too stupid to recognize that the dots aren't representing letters when they use this software, and instead appricate it as a kind of art.
The braille displays you typically encounter will only display one line of braille at a time.
You are telling me that a blind person will be able to remember the entire line of gibberish as the geometric shape gets "printed" line by line and then remember those at 30 frames per seconds?
Come on, it's not about being too stupid to understand. It's about this technology having nothing at all to do with the blind except for hijacking useful Unicode characters.
I can't wait until people rediscover Sixels and get actual graphics in the terminal in a network-transparent fashion. Modern terminal emulators support it, it just isn't widely known.
xterm supports Sixels, and I'd be surprised if it were the only one.
And this library enables things like video and X11 using Sixel, plus it has a list of terminals which support Sixels in the README: https://github.com/saitoha/libsixel
MacTerm implements TEK 4014 and 4105 graphics (MacTerm is my project). Support for TEK graphics does seem rare though; aside from "xterm" and "gnuplot", I can’t think of anything else that uses those commands.
Drawille works in MacTerm too; I ran some of the example programs just now. Neat, especially the rotating cube. :)
My previous attempt at a pithy complaint pointing out the license of this project was flagged, so I will attempt to provide a bit more value:
This is a great idea and would be nice even just as an art project but unfortunately I can't do much personally useful with it.
The choice is 100% up to the author and I respect how they avoid losing control of their IP. It is interesting to see the uptake and I wonder how many project using this tool are in violation of the license.
This is a really neat looking project (and the GH readme references the original HN discussion). For folks who are generally into TTY UIs and dashboards, I also want to point out the Blessed terminal rendering lib and its ecosystem (which even includes a React bridge!):
The resulting pixel resolution is a bit screwy, especially if you use a tall, thin font like the one I tend to. Too many pixels horizontally, too few vertically. The upper block/lower block characters might be better in terms of aspect ratio, but then the overall resolution is made even worse...
I've dreamed about doing an automated "ASCII"-art converter that utilizes all of Unicode. You could accomplish some pretty crazy line art if you put your mind to it, but the analysis would be super challenging.
Also you'd either need a monospace Unicode font (which I don't imagine has anywhere near 100% glyph support) or incorporate spacing and kerning rules...
I would think about feeding rendered unicode characters to train a visual algorithm about which character may match, then "on the go" do a bitmap comparison to select the best one for the given case.
The first part could be something like shapecatcher.com where you select the top N plausible candidates, then on the final part you select the best one for the case at hand. (well at least that's how I would try to implement that first)
