Hans Hagen a écrit :

there will be no built in otf engine or any engine

(context comes with one written in lua; at some point i will make a spin-off for plain tex that then also can be used elsewhere)

Ok... I still want to help with OTF support, whatever the solution, so if you need any help, just ask me. -- Elie

Taco Hoekwater wrote:

Elie Roux wrote:

...

Hans Hagen a écrit :

...

there will be no built in otf engine or any engine

(context comes with one written in lua; at some point i will make a spin-off for plain tex that then also can be used elsewhere)

Ok... I still want to help with OTF support, whatever the solution, so if you need any help, just ask me.

It makes sense to start with that generalization of the otf processing sooner rather than later, so maybe Elie could start studying the context font-related lua files?

best wait a month or so, till we have the math table done as well; i might change a few things in the process; once we have math going, i expect the font related data structures (in mkiv as well ad luatex itself) to be quite stable 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 -----------------------------------------------------------------

Barry Schwartz wrote:

It's probably a good idea to have many eyes looking at that code, because there seems to be a tendency to implement feature support incorrectly (including myself when I first started dealing with OpenType features in my hobby work). A common effect that I have seen with both Ant and HarfBuzz is for ligatures to be applied before small-caps-substitution.

well, one reason for doing it in lua is that there can be several solutions and i'm pretty sure that there will be; the code used in context mkiv can be a starting point (it will have hooks and such) but i know the tex community good enough to know that different solutions will pop up; also, since ms and adobe and whoever seem to interpret things differently we might end up with even more variants (apart from the need to deal with buggy fonts) (btw, so far i made three variants just to get an idea of open type and curently i'm making a new one) one thing that would help is simple test fonts (like the ones that idris makes, so that's one area where help is needed)

It is important to keep in mind that features are not ordered; they are simply sets of lookup indexes. What you do is compute the union of all the lookups of the selected features, and then do the lookups in the order they appear in the lookup table.

indeed

It concerns me a little that LuaTeX should be able to handle ligatures but not line-breaks in the middle of ligatures, because ligature-lookups in OpenType are handled just like any other substitution lookup. They don't require any special code different from that of other lookup types; from my point of view, LuaTeX shouldn't have to know anything about ligatures, just how to select and execute lookups.

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

I studied the mkiv code several weeks ago but never in enough depth to see what was going on in there. Also I don't know much at all about OpenType support for non-LGC scripts.

i expect to have more final code sometime in januari 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 -----------------------------------------------------------------

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 -----------------------------------------------------------------