Mike Ayers wrote:
In most sectors, the answer is "not anymore". However, the ability to programatically assemble glyphs instead of using precomposed glyphs, assuming that this requires less resources, would be very desireably in embedded consumer applications (organizers, phones, etc.) where cost savings are at a premium. Some programmatic support already exists, but I think that we are a few generation's worth of research away from, say, the 13 glyph Chinese font. For the meantime, following the path of precomposed glyphs makes the most sense.
Programatically assembling glyphs at run time from a small library of components is often not very efficient since it can result in numerous calls to the layout engine, instead of a single substitution lookup. If you can make glyphs from a small number of components at run time then you can also pre-assemble and pre-position those same components in *composite* glyphs. With this approach you only have the same number of actual outlines in your font file as in a font where the parts are assembled, positioned and sized at run time.
Of course this approach does not give the end user quite the same flexibility to productively generate new combinations. But productive
generation is not possible anyway if the necessary lookups are not there.
I should also point out that Peter, like many advocates of glyph composition, seems to believe that this would be an easier path. This would probably be true in the end, but along the way is much, much more work. Ironically, part of that work would probably include assemblage of the very database of precomposed glyphs that he argued against - so that the data for composition of each individual composed glyph (deformation, position, magnification, etc.) can be generated and checked. Yes, it would be a monumental achievement, but a pretty cool one, all said and done.
You are right about all the work required and the necessity of some kind of database.
Yes the results would be "cool" - but when you do this it turns out that viewing and reflowing large documents in a WYSIWYG application slows to a crawl - and it can end up that where the correct ligatures not formed as fast as the underlying characters are typed typed in which is particularly disconcerting for the user. As you infer with a really complex script and a large glyph repertoire to be generated, the number and complexity of the lookups would takes a huge effort and makes a font very complex to test, debug and maintain. In practice this only ends up limiting the number of fonts available for a system and increases the cost and difficulty of development and ultimately paid for by the end users.
When you try to reduce the number of component parts to a minimum it is also very easy to end up making sacrifices in terms of design.
- Chris
