Barry Schwartz wrote:
Hans Hagen <[email protected]> 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
-----------------------------------------------------------------
_______________________________________________
dev-luatex mailing list
[email protected]
http://www.ntg.nl/mailman/listinfo/dev-luatex
