Seems to be matching against one particular typeface, and is very sensitive to how similar what you write is to that typeface. The first thing I tried was a lowercase "a," which, in my handwriting, is a one-story "a," and it had no idea what it was. Likewise it guessed poorly at my lowercase "f" because the top of my "f" curves back down, and its doesn't, etc. Seems like it would benefit from a dataset with more variations on how various characters are written in practice.
I tried multiple times to match an ampersand, and thought I did a fairly accurate job.
I eventually managed to get it as a third match, but this seems to be what it matches against [0], which isn't the ampersand I'm used to (nor the one you get in a google image search).
Only halfway related, but a long time ago I had an idea for a character encoding that was stroke based.
In other words, based on minimal stroke primitives (line, arc, circle, etc.) that were placed not with any exact coordinates, but simply in relation to each other conceptually and with crude size/position categories. E.g. "downward stroke, top to bottom" is a capital "I" while "downward stroke, middle to bottom, dot closely above first stroke" would be a lowercase "i". And then for matching forms with different meanings, there would be a final "family" selector, e.g. to distinguish an em-dash from the Chinese character for "one", or an en-dash ("punctuation" family) from a minus sign ("math symbol" family).
And then a suitably compressed bit encoding for the instructions. So in the end, something like "I" might just be 3-4 bits long, while a complex Chinese glyph might be 60 bits.
But the main feature being that a font renderer could always draw a primitive version of any glyph, even if you don't have it in a single font anywhere, because the character code itself encodes it. And then that character codes wouldn't be just something totally arbitrary invented by Unicode, but inherently meaningful, and anyone could be free to invent any character they wanted, that would always been drawn by any software, no Unicode gatekeepers needed.
Obviously it's not terribly practical, for a whole host of reasons. But I still sometimes think about how elegant it would be to have a "geometric" self-describing character encoding, and to get away from all of the political decisions around language scripts and where they get put in Unicode and in which version.
Problem is, how do you define these representations in the first place? For one thing, some characters have multiple different forms… like a/ɑ, or g/ɡ [0]. Then you have characters which differ only minutely — like Thai ช/ซ, or Ethiopic ሀ/ህ, or Cherokee Ꭺ/Ꭿ. And, worse, those characters can also look entirely different between fonts (see e.g. [1] for Thai). So by the time you’ve finished working through all those choices, and created a format which can distinguish them all, you’ve effectively created yet another font — just in a very lossy vectorised format.
Or if you go the opposite direction, and expect each individual character to make its own individual choices in this regard — well, that basically has the same problems as PDFs: it may look good, but it’s totally impossible to process programmatically, since it overspecifies the visual details at the expense of semantics. And although that might be fine and even desirable for certain usecases, it does limit the places where this format could be used.
That being said, I can certainly see possibilities and places where this could be useful to me. Perhaps I’ll have a go at implementing this someday.
[0] In case those look the same in your font, here they are again:
a/ɑ g/ɡ
And in case those look the same too, then… well, have a look at the codepoints in the Unicode reference charts, I guess!
It's an interesting idea, my first thoughts are how do you make it machine readable. Like if you're writing a browser how do you translate something that "looks" like google.com and know you need to go to google.com and not googIe.com?
Maybe you don't bother (i.e., don't try to parse bytes in this encoding as plain text) but that has a bunch of consequences too.
This doesn't appear to even try to match to Chinese characters? I drew the ones for convex and concave (凸 and 凹, respectively), but only got back dominoes and APL symbols as matches. Drawing a box returns the Japanese katakana ロ, but not the Chinese hanzi 口.
Tried it with β and with ξ but did not get a match.
(Disclaimer, I did eventually get the β working, but first versions only gave other results such as P, ρ or Բ).
I'm using these for documentation and monodraw is only useful up to a point and references to these are scattered in different pages in no relation for drawing purposes.
I tried drawing a \, but shapecatcher only show just "\" and only if it's semi-close to 45°.
Edit: Thanks @mapierce2 , Detexify seems to work better for this purpose, but the results seems to be images, not text.
Snowman didn't work for me, but the other characters I tried did. I had some trouble with "therefore" because there were a lot of virtually identical symbols, but I can't blame it for that.
It mentions not all characters are in the the database.
[+] [-] apendleton|3 years ago|reply
Neat concept though!
[+] [-] croon|3 years ago|reply
I eventually managed to get it as a third match, but this seems to be what it matches against [0], which isn't the ampersand I'm used to (nor the one you get in a google image search).
[0] https://shapecatcher.com/unicode_img/38.png
[+] [-] Symbiote|3 years ago|reply
[+] [-] crazygringo|3 years ago|reply
In other words, based on minimal stroke primitives (line, arc, circle, etc.) that were placed not with any exact coordinates, but simply in relation to each other conceptually and with crude size/position categories. E.g. "downward stroke, top to bottom" is a capital "I" while "downward stroke, middle to bottom, dot closely above first stroke" would be a lowercase "i". And then for matching forms with different meanings, there would be a final "family" selector, e.g. to distinguish an em-dash from the Chinese character for "one", or an en-dash ("punctuation" family) from a minus sign ("math symbol" family).
And then a suitably compressed bit encoding for the instructions. So in the end, something like "I" might just be 3-4 bits long, while a complex Chinese glyph might be 60 bits.
But the main feature being that a font renderer could always draw a primitive version of any glyph, even if you don't have it in a single font anywhere, because the character code itself encodes it. And then that character codes wouldn't be just something totally arbitrary invented by Unicode, but inherently meaningful, and anyone could be free to invent any character they wanted, that would always been drawn by any software, no Unicode gatekeepers needed.
Obviously it's not terribly practical, for a whole host of reasons. But I still sometimes think about how elegant it would be to have a "geometric" self-describing character encoding, and to get away from all of the political decisions around language scripts and where they get put in Unicode and in which version.
[+] [-] bradrn|3 years ago|reply
Or if you go the opposite direction, and expect each individual character to make its own individual choices in this regard — well, that basically has the same problems as PDFs: it may look good, but it’s totally impossible to process programmatically, since it overspecifies the visual details at the expense of semantics. And although that might be fine and even desirable for certain usecases, it does limit the places where this format could be used.
That being said, I can certainly see possibilities and places where this could be useful to me. Perhaps I’ll have a go at implementing this someday.
[0] In case those look the same in your font, here they are again:
And in case those look the same too, then… well, have a look at the codepoints in the Unicode reference charts, I guess![1] https://wrdingham.co.uk/thai/tellthai_preface.htm
[+] [-] lifthrasiir|3 years ago|reply
[1] https://datatracker.ietf.org/doc/html/rfc5242
[+] [-] bentcorner|3 years ago|reply
Maybe you don't bother (i.e., don't try to parse bytes in this encoding as plain text) but that has a bunch of consequences too.
[+] [-] keybored|3 years ago|reply
[+] [-] mapierce2|3 years ago|reply
http://detexify.kirelabs.org/classify.html
[+] [-] hnlmorg|3 years ago|reply
[+] [-] wcoenen|3 years ago|reply
https://www.qhanzi.com/
[+] [-] dontlaugh|3 years ago|reply
[+] [-] yellow_lead|3 years ago|reply
[+] [-] roland35|3 years ago|reply
[+] [-] marginalia_nu|3 years ago|reply
... but not ℏ.
[+] [-] rippercushions|3 years ago|reply
[+] [-] nyx|3 years ago|reply
> Currently, there are 11817 unicode character glyphs in the database. Japanese, Korean and Chinese characters are currently not supported.
[+] [-] plank|3 years ago|reply
[+] [-] BugsJustFindMe|3 years ago|reply
[+] [-] Isognoviastoma|3 years ago|reply
[+] [-] scatters|3 years ago|reply
[+] [-] fuzzythinker|3 years ago|reply
different angles of /, \
etc...
I'm using these for documentation and monodraw is only useful up to a point and references to these are scattered in different pages in no relation for drawing purposes.
I tried drawing a \, but shapecatcher only show just "\" and only if it's semi-close to 45°.
Edit: Thanks @mapierce2 , Detexify seems to work better for this purpose, but the results seems to be images, not text.
[+] [-] psidebot|3 years ago|reply
[+] [-] maxbond|3 years ago|reply
It mentions not all characters are in the the database.
ETA: it's got a pretty weird snowman. http://shapecatcher.com/unicode/info/9731
By immitating this rendition I was able to bring it up.
[+] [-] chrisux|3 years ago|reply
It would be nice for it to also give alt codes for it in the output
like é = [alt 1 3 0]
[+] [-] lokedhs|3 years ago|reply
[+] [-] SecurityNoob|3 years ago|reply
[+] [-] quechimba|3 years ago|reply
[+] [-] singularity2001|3 years ago|reply
[+] [-] wruza|3 years ago|reply
Doesn’t recognize.
[+] [-] 6451937099|3 years ago|reply
[deleted]
[+] [-] o_____________o|3 years ago|reply
[+] [-] thom|3 years ago|reply
[+] [-] keybored|3 years ago|reply