Re: [Dev-luatex] OTF engine in LuaTeX

Barry Schwartz wrote:

Hans Hagen skribis:

...

not even that, you just (re)construct node lists and manipulate glyph nodes (which can have lig info)

I just get concerned when I see reference to stuff like ligature info, because in general, and speaking in part as an amateur font designer, it seems difficult to stray from just strictly following the algorithm (an algorithm that is treated oddly casually in the spec). For example, once you throw in contextual alternates and contextual ligatures, you have two or more lookup tables to go through, with any number of single, multiple, and ligature substitutions, which have to be performed in order. Just throwing in 'dlig' along with 'liga', or even just one of them, is likely to get you two or more lookups to go through, with arbitrary substitutions performed in-between. In general, how can one know what the result will be without just going through lookup lists or equivalent data structures?

one cannot, which is why i think that fonts will have bugs and since font vendors have no update program (bug fixes) one is then stuck with this problem add to that the fact that when something works in the designers favourite program (which isthen seen as standard) changes are low that it will be fixed; but the same is true for features in general: when (say) indesign 2 does not support something (thereby hiding bugs in fonts) but version 3 does ... what is the standard? the indesign defaults? ligatures are kin dof manageable but think of frac and friends: often implemented partially so unpredictable for global usage; it assumes that one 'selects a piece of text in a gui and applies that feature'; a tex macro package can deal with that better by providing some mechanism that is clever enough to see if something is in the font or not

I've moved on to wonder how best to handle chaining contextual substitutions that look at glyphs in more than one word at a time.

always tricky .. crossing word boundaries (what is a boundary? space? small kern?) and it also concerns line breaks (which might alter things) we're experimenting with alternative arabic typesetting, using info stored in features but applying different algorithms Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------