Accurately portraying some of the comedy in i people going “oh I don’t need fancy graphics, I just use text”. To add some fun to just how dark the technical world of the ‘ligature’ can be: Start with this little bundle of joy: https://docs.microsoft.com/en-us/typography/opentype/spec/gsub
So you get this scary little weird machine hidden inside the font that takes 1..n codepoints and spits out 1..m glyph indices. You basically need to be able to pass it around with complex documents or it won’t be legible, so for a networked application, the ‘font’ is a state blob that needs to be synched on both sides (enter CSS3/cufon), after all, this can turn ‘truth’ into ‘lies’ given the right font. Then you have your other ‘crazy write / unpack’ primitive with the ‘x-advance, y-advance’ output from kerning and hinting.
A fun little way to say, encode malware payload inside something no AV will unpack or really flag as suspicious.
some of the comedy in i people going “oh I don’t need fancy graphics, I just use text”
To be fair, using a GUI means doing all of text ‘right enough’ and having extra stuff on top. It’s just that, so long as you can accurately size chunks of text, the stuff that’s specific to drawing GUIs (like handling positioning of non-overlapping widgets, tying events to potentially-overlapping windows, avoiding drawing hidden items, eliminating flicker, etc.) is trivial in comparison, since it doesn’t need to be an accurate analogue of an ink-and-paper technology.
I love it. I have a fascination for text rendering, how it merges so many fields together and at the same time appear seamless to users.
Here’s a list of good articles on the topic for anyone interested:
Between this article, and the one about the length of Unicode strings it’s almost enough to make me stick my fingers in my ears and run around going “la la la la la la!” while thinking sweet thoughts about ASCII.
Text rendering can be quite hard even if you avoid or hand off most of the complications mentioned in this document.
I had some experience with this, as a side effect of working on some internal Xanadu prototypes. We were willing, for the sake of these prototypes, to support only languages written left to right & only in a single full-unicode font; in the non-glyphcache-oriented versions, we also supported arbitrary ligatures by relying upon SDL or QT rendering (and we separated only at line boundaries or at selection boundaries – i.e., if two contiguous characters were from different sources, were part of different sets of links, or had formatting differences). Nevertheless, language-agnostic text layout is tough: when is it safe to wrap when you have a mix of languages? We ended up doing word wrap based on english language rules & then falling back to character wrap if a single ‘token’ was too long, which is bound to be wrong a lot of the time but is ‘sane enough’.
If you’ve got a big localization team full of professional polyglots then you can add all sorts of special cases & get something that looks professional in most languages, but if you’re two guys working for free three or four hours a week & text rendering isn’t even your main concern, looking professional in both japanese, arabic, & koine greek isn’t in the cards.
Is this a case where a little bit of simplification at one end can result in a lot of simplification at the other end? If Arabic or Thai suddenly had a non-script version, wouldn’t that help font rendering?
European scripts are generally easier to process mechanically. Some people hold this ups as evidence of Euro-centric bias on behalf of the people who designed computer systems and things like Unicode, but it’s also the case that European scripts have been simplified over centuries. Gutenberg’s printing press encouraged writing to be much simpler and more uniform than the hand-written documents that preceded it, Linotype machines made things simpler again, typewriters forced people to simplify even further, so by the time computers came around, it wasn’t hard for them to meet the low standards people expected.
I imagine if Arabic countries had had four centuries of relentless industrialisation, their script would likely be a whole lot simpler and easier for computers to render, too.
But they haven’t had that influence, and people want computers to read and write the script they already know, rather than adapt to something with greater mechanical sympathy, so it’s not really a practical alternative. Computers could be much simpler if everybody gave up their native language and only used, say, Lojban, but it’s not going to happen.
If anyone wants to see traditional chinese typefaces in person, pay a visit to Ri Xing Type Foundry in Taipei. There are a few representative pictures on someone’s blog here.
Good point! So it’s probably a combination of the dog wagging the tail and the tail wagging the dog. Though China’s history is also about as complex and subtle as possible, so if you then start to ask questions like “Why didn’t they slowly evolve a simpler form?” you get into all sorts of interesting things, especially in the Song dynasty.
I know this was probably not your intent, but suggesting that hundreds of millions of people should give up thousands of years of shared cultural experiences for the benefit of a few computer programmers is the essence of cultural imperialism ;)
If Arabic or Thai suddenly had a non-script version, wouldn’t that help font rendering?
In general, adding new features doesn’t help with simplification, because it simplification can only happen when requirements are removed. If a non-cursive Arabic were suddenly introduced, it wouldn’t make Arabic users suddenly decide that they never needed cursive rendering. (I’m assuming by “script” you mean “cursive script” because “non-script” isn’t really a term that makes any sense; even so, Thai has never been cursive; maybe you meant Devanagri?)
Shoutouts to all those enthusiastic Firefox developers out there. After the third time, that had me laughing.
Accurately portraying some of the comedy in i people going “oh I don’t need fancy graphics, I just use text”. To add some fun to just how dark the technical world of the ‘ligature’ can be: Start with this little bundle of joy: https://docs.microsoft.com/en-us/typography/opentype/spec/gsub
So you get this scary little weird machine hidden inside the font that takes 1..n codepoints and spits out 1..m glyph indices. You basically need to be able to pass it around with complex documents or it won’t be legible, so for a networked application, the ‘font’ is a state blob that needs to be synched on both sides (enter CSS3/cufon), after all, this can turn ‘truth’ into ‘lies’ given the right font. Then you have your other ‘crazy write / unpack’ primitive with the ‘x-advance, y-advance’ output from kerning and hinting.
A fun little way to say, encode malware payload inside something no AV will unpack or really flag as suspicious.
To be fair, using a GUI means doing all of text ‘right enough’ and having extra stuff on top. It’s just that, so long as you can accurately size chunks of text, the stuff that’s specific to drawing GUIs (like handling positioning of non-overlapping widgets, tying events to potentially-overlapping windows, avoiding drawing hidden items, eliminating flicker, etc.) is trivial in comparison, since it doesn’t need to be an accurate analogue of an ink-and-paper technology.
I love it. I have a fascination for text rendering, how it merges so many fields together and at the same time appear seamless to users.
Here’s a list of good articles on the topic for anyone interested:
And there’s a list in the first entry of this newsletter https://newsletter.nixers.net/entries.php#135
Between this article, and the one about the length of Unicode strings it’s almost enough to make me stick my fingers in my ears and run around going “la la la la la la!” while thinking sweet thoughts about ASCII.
does it help if you just think of it as logo turtle graphics on acid? :)
Text rendering can be quite hard even if you avoid or hand off most of the complications mentioned in this document.
I had some experience with this, as a side effect of working on some internal Xanadu prototypes. We were willing, for the sake of these prototypes, to support only languages written left to right & only in a single full-unicode font; in the non-glyphcache-oriented versions, we also supported arbitrary ligatures by relying upon SDL or QT rendering (and we separated only at line boundaries or at selection boundaries – i.e., if two contiguous characters were from different sources, were part of different sets of links, or had formatting differences). Nevertheless, language-agnostic text layout is tough: when is it safe to wrap when you have a mix of languages? We ended up doing word wrap based on english language rules & then falling back to character wrap if a single ‘token’ was too long, which is bound to be wrong a lot of the time but is ‘sane enough’.
If you’ve got a big localization team full of professional polyglots then you can add all sorts of special cases & get something that looks professional in most languages, but if you’re two guys working for free three or four hours a week & text rendering isn’t even your main concern, looking professional in both japanese, arabic, & koine greek isn’t in the cards.
Is this a case where a little bit of simplification at one end can result in a lot of simplification at the other end? If Arabic or Thai suddenly had a non-script version, wouldn’t that help font rendering?
European scripts are generally easier to process mechanically. Some people hold this ups as evidence of Euro-centric bias on behalf of the people who designed computer systems and things like Unicode, but it’s also the case that European scripts have been simplified over centuries. Gutenberg’s printing press encouraged writing to be much simpler and more uniform than the hand-written documents that preceded it, Linotype machines made things simpler again, typewriters forced people to simplify even further, so by the time computers came around, it wasn’t hard for them to meet the low standards people expected.
I imagine if Arabic countries had had four centuries of relentless industrialisation, their script would likely be a whole lot simpler and easier for computers to render, too.
But they haven’t had that influence, and people want computers to read and write the script they already know, rather than adapt to something with greater mechanical sympathy, so it’s not really a practical alternative. Computers could be much simpler if everybody gave up their native language and only used, say, Lojban, but it’s not going to happen.
Movable type was actually invented first in China by Bi Sheng but didn’t take off there because the character set was too large.
If anyone wants to see traditional chinese typefaces in person, pay a visit to Ri Xing Type Foundry in Taipei. There are a few representative pictures on someone’s blog here.
Good point! So it’s probably a combination of the dog wagging the tail and the tail wagging the dog. Though China’s history is also about as complex and subtle as possible, so if you then start to ask questions like “Why didn’t they slowly evolve a simpler form?” you get into all sorts of interesting things, especially in the Song dynasty.
They did eventually make a simpler form, although it’s still has way more symbols than almost every other language.
I know this was probably not your intent, but suggesting that hundreds of millions of people should give up thousands of years of shared cultural experiences for the benefit of a few computer programmers is the essence of cultural imperialism ;)
In general, adding new features doesn’t help with simplification, because it simplification can only happen when requirements are removed. If a non-cursive Arabic were suddenly introduced, it wouldn’t make Arabic users suddenly decide that they never needed cursive rendering. (I’m assuming by “script” you mean “cursive script” because “non-script” isn’t really a term that makes any sense; even so, Thai has never been cursive; maybe you meant Devanagri?)