3 ms·

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

by bradrn 4y ago

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! [1] https://wrdingham.co.uk/thai/tellthai_preface.htm https://wrdingham.co.uk/thai/tellthai_preface.htm

crazygringo 4y ago
Yup, I didn't say it would be easy. :) But initial thoughts are simply that characters would be defined "canonically" (for progammability) with fonts free to vary stylistically as desired just as they are now (for the classic single- and double-story 'a' and 'g' you mention, for instance.) While minute differences within any language should be handled by the strokes themselves or else the final "family" selector I mentioned when strokes are identical (is it an en-dash or a minus sign). Again, more of a thought experiment of how character encoding might have gone a different way in the past. And because canonical forms would be required for interoperability it would still need a coordinating body (like Unicode) to standardize them, but people would still be free to encode their own meaningful characters outside of the standards (such as rare/ancient family name characters in Chinese that aren't in Unicode). What's really fun to think about is how rendering libraries might even use machine learning to draw glyphs when no font glyph is available, in the style of an existing font, whether a garamond serif, or brush Chinese.

by bradrn 4y ago

crazygringo 4y ago

Yup, I didn't say it would be easy. :) But initial thoughts are simply that characters would be defined "canonically" (for progammability) with fonts free to vary stylistically as desired just as they are now (for the classic single- and double-story 'a' and 'g' you mention, for instance.) While minute differences within any language should be handled by the strokes themselves or else the final "family" selector I mentioned when strokes are identical (is it an en-dash or a minus sign). Again, more of a thought experiment of how character encoding might have gone a different way in the past. And because canonical forms would be required for interoperability it would still need a coordinating body (like Unicode) to standardize them, but people would still be free to encode their own meaningful characters outside of the standards (such as rare/ancient family name characters in Chinese that aren't in Unicode). What's really fun to think about is how rendering libraries might even use machine learning to draw glyphs when no font glyph is available, in the style of an existing font, whether a garamond serif, or brush Chinese.