Overstrike makes ASCII the first multi-byte encoding of an internationalized character set (for the Latin family of scripts anyways).
I'm not kidding. The ASCII character set was actually designed to permit overstriking to yield a variety of characters such as, e.g., á. But of course, this follows from the fact that the typefaces used in typewriters were so designed. Historically that is how people wrote characters like á and ç back in the age of typewriters. This is also why Spanish rules made accents on capital letters optional: it wasn't easy to typeset those on typewriters.
The way to encode á, then, was: a BS ' (a, backspace, apostrophe).
Do I have sources for this? I've lost track of them, and I'm not going to look just now...
The Teletype doesn't do backspace (!) but can do carriage-return... so e.g. to print "Björk" , the text is: BJORK(CR)(space)(space)(quote). I have a Teensy microcontroller that already handles some ANSI-escape characters, and implements the 'backspace' ^[[D this way (https://github.com/hughpyle/ASR33/blob/master/firmware/ansi_...). Next on the backlog is "bold", using a similar strategy. Fun times :)
This is awesome. You might want to add "Printed" to the front of your title, because I've seen quite a few ASCII art projects before and almost skipped over this, but the fact that it's printed is quite novel to me at least.
I was wondering if I should try this for a more complete set of unicode characters (opposed to just block graphics), but I'd need find a good way to match slightly off positioning. Perhaps just register the same character multiple times, shifted by one px in each direction?
Very interesting - thanks for the link. (This is exactly what I hoped HN would show me!)
Several interesting things there. The use of Structured Similarity Index (SSIM) is probably better/faster than the Histogram of Oriented Gradients (HOG) that my project uses. And then, at runtime, I'm still doing a brute-force match (which is really slow) -- clearly there are big performance gains to be made by training a classifier.
After some more investigation... their paper is interesting. But: it's $25 to download their model file, and the trainer code and training dataset aren't published. Oh well.
Wow, those are some impressive results! I've been wanting to do some ascii art on a dot-matrix printer for a little while now, and I was thinking of something similar to your "sub-pixel rendering" but had no idea how to research/implement it. I look forward to reading through your code and references more, and I really appreciate the history that you've written up here.
Very very cool. I love their approach of looking for similarity metrics that are less sensitive to local misalignment, and this is something I'me very interested in exploring in the future.
I'm not completely convinced by their distinction between "tone-based" and "structure-based", though. When they talk about structure, it seems to primarily mean 'edges'. Instead maybe a more useful distinction would be between "local optimization" (at the level of a single printed character), and optimizing "globally" or over a wider area of the image, and so allowing an iterative optimizer to find a really compact representation.
I'm not kidding. The ASCII character set was actually designed to permit overstriking to yield a variety of characters such as, e.g., á. But of course, this follows from the fact that the typefaces used in typewriters were so designed. Historically that is how people wrote characters like á and ç back in the age of typewriters. This is also why Spanish rules made accents on capital letters optional: it wasn't easy to typeset those on typewriters.
The way to encode á, then, was: a BS ' (a, backspace, apostrophe).
Do I have sources for this? I've lost track of them, and I'm not going to look just now...