The history of luaTEX 2006–2009 / v 0.50 - Pragma ADE

of them. Each lookup has a detailed specication of what language and/or scripts it
applies to.
• For each lookup we do a run over the list of glyphs. So, if we have 50 lookups, and a
paragraph has 500 glyphs, we do some 25000 loops. Keep in mind that for arab we
start with a sequence of characters and vowels, and during a run, these might be replaced
by for instance ligatures and combined vowels, so the 500 stepwise becomes
less.
• We only process the features that are enabled. Normally the lookups are organized
in such a way that features take place in a similar way: (de)composition, replacement
of initial, medial, nal and isolated forms, specic replacements by one or more variant,
composition of ligatures, mark positioning, cursive corrections and kerning. The
font itself does not contain information about what features are to be enabled by default.
Some applications have built in presets, others might extend their repertoire
over time.
• A lookup can be a contextual lookup, which means that treatment takes place on a
match of a sequence of characters (glyphs), either of not preceded or followed by
specic other characters (glyphs). We we loop over all contexts till we have a match.
Some fonts have lots of contextual lookups, which in turn might increase the number
of loops over the list of characters (glyphs). If we have a match, we process the
associated list of sublookups. Technically it is possible to replace (say) ve characters
by rst a ligature (that replaces the rst two by one), then a multiple substitution
(resulting in an extra three glyphs replacing one) and then discarding the other rest
(being two characters). Because by that time characters (say, unicode points) might
have been replaced by glyphs (an index in the font) a contextual lookup can involve
quite some match points.
In ConTEXt we do this for each font that is used in a list, so in practice we have quite some
nested loops. Each font can have its own set of features enables of features might be
applied dynamically, independent of font related settings. So, around the mentioned
loops there is another one: a loop over the fonts used in a list (paragraph).
We process the whole list and then consult the glyph nodes. An alternative approach is to
collect strings of characters using the same font including spaces (because some lookups
involve spaces). However, we then need to reconstruct the list which is no fun. Also, we
need to carry quite some information, like attributes, so eventually we don't gain much
(if we gain something at all).
Another consideration has been to operate on sublists of font usage (using a subhead
and subtail) but again this would complicate matters as we then neext to keep track of
a changing subhead and subtail. On the other hand, this might save some runtime. The
250 Tracking