Add suport for AAT lookups #1025
Conversation
After this change, the `morx` table in Zapfino.ttf can be ttx'ed again.
Currently, this makes no difference at all. Later, we'll use this for dispatching AAT lookup types in the same way how we already dispatch OpenType lookup types.
Needs more work.
We now produce the correct binary search headers, and add a fake item for terminating the binary search.
For AAT lookup format 2 (and other formats too), we need to shuffle the data before we can estimate the encoded size. After this restructuring, this data shuffling only needs to happen once.
With AAT, the same lookup data structure can be used for various types of values. In the morx table, the values are glyph IDs or glyph classes, which both are encoded as 16-bit unsigned integers. In other AAT tables, however, the values can be different data types with different encodings. By passing a `valueWriter` callback and explicit `valueSize`, we prepare for eventually templatizing the building of AATLookups. Also, assert that the called writer wrote the exact number of bytes that was predicted when figuring out what format should be used for encoding an AATLookup.
To use self.valueConverter.read(), we will need to pass the font.
Temporarily removing the `morx` table from the table list so that the rest of the AAT work can be merged into master.
|
Curious why you're investing into implementing AAT at this point, aren't almost all fonts OpenType or Type1 nowadays? |
|
The state tables model in AAT is said to be about 3x faster in processing than OpenType Layout, especially for complex scripts. It's kind of like the difference between a compiled (AAT) and an interpreted (OTL) language. Glyph layout based on the basis of a single font is a finite business, so it could be expressed using a static "cache", which morx largely is, but OpenType uses a dynamic model and queries all the active lookups on every glyph in a run. Of course a platform can implement a custom cache on their own, but that wouldn't be portable. On the other hand, AAT (esp. morx) already can serve for this, and has the benefit of being supported on the Apple platforms Mayberry natively, so there is an independent implementation which makes testing easier. AFAIU, OTL tables can be losslessly converted into morx state tables (though it may require automated addition of some glyphs). If such an automatic module was developed, it could give a significant speed boost for the processing. I could imagine makers of platforms like Android or Chrome welcoming such a development. |
|
Even if one does not go full AAT model, some of its tables seem to be interesting. For example |
This statement is only partially true. It's prohibitively hard to convert anything using the Indic shaper to such AAT fonts. For Universal Shaping Engine, it might be possible, but would require encoding the Unicode data part of USE in the font, which negates the point of USE. For Arabic, Hangul, Thai, and Latin/simple scripts this is possible, but then it's of questionable import, since code still has to be prepared for super-slow fonts and as such needs to cache shaping results the way everyone currently is doing. |
Although there is more work to be done before fonttools can handle
morxtables,I’d like to merge the current state of the AAT work into master so it does not bitrot.