> Based on your project I inferred that adding more matches seems to add more resolution and yeah, outputs are looking even nicer now. I updated the repo!
This is the right approach, but there's a combinatory explosion when computing the matches: you want to select a subset of shapes that in practice are more often right, to save on the matching computation time.
Also, when you are operating with time constraints (ex: video to text), keeping the FPS rate is often more important that the accuracy, as the human eye does a lot of interpolation.
Having different subsets of different sizes and a command-line toggle between them seems like the simpler approach to support multiple uses.
> I also used shapes which are less sharp rather than "perfect match".
Selecting some "less sharp" glyphs is a very daring and unique idea: in retrospect, it should help the bad cases by adding some "blur".
I really like you idea!
Would you be interested in a collaboration to inspect fonts and select glyphs based on 1) their availability (ascii>ansi>unicode) 2) their usefulness (by defining some subsets)
I saw your message but was hesitant to respond with disappointment.
I'm sorry my interest in this is not as large as yours!
I think the end result could be cool, but overall not very practical. I wrote my program to include "images" in my text-only articles (http://len.falken.ink/philosophy/is-privacy-in-all-our-inter...), but really I can't imagine a real useful application. We (the world) is much better off to adopt a real "images with text" format which works nicely with terminals (for now this appears to be sixel and the proposal by kiTTY).
My email is inbox at lee <this username> dot ca :)
