From: Christopher Fynn (email@example.com)
Date: Sat Sep 25 2004 - 09:16:10 CDT
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
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
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.
This archive was generated by hypermail 2.1.5 : Sat Sep 25 2004 - 09:20:38 CDT