I have two questions/suggestions concerning AAT.
I am developing fonts with AAT. While I like FontForge a lot, for
adding AAT I prefer Apple's font tools, since my FontForge build (I
have installed FontForge with FontForge_intelmacX.4_x86-
py23-20090914.pkg.zip) is likely to crash when I do AAT stuff.
Now there's that thing about AAT kerning: I have found no other tool
but FontForge to add AAT kerning to a font. For Mac OS 9, there
appearently were the tools DumpKERN and FuseKERN. The Apple Font Tool
Suite Tutorial mentions: "In addition to MIF files, you can also
define text input files for Kerning (KIF) and Justification (JIF).
These formats are described in the Font Tool Suite document." This,
however, seems to be an empty promise. Justification input files (JIF)
are described, but there is no other mention of kerning input files.
Also, the usage information of "ftxenhancer -h", the tool used for
adding morph input files (MIF) or justification input files (JIF),
does not mention any kerning input files at all.
I wonder whether there is a way to add AAT kerning to a font via
Apple's font tools. It would be great if that ominous "Kerning Input
File" really existed. Do you know anything about it? I have been able
to do some AAT kerning via FontForge. However, that is tedious since,
as I've said, my FontForge is likely to crash when I do things like
that. I would also very much prefer writing the AAT kerning
information in a text editor (like a Morph Input File), than clicking
through it in FontForge's GUI.
With regard to the capabilities of AAT's contextual substitution, the
section "Why can't all contextual/chaining tables be converted?" of
the FontForge documentation page "Advanced Typography Tables" ( http://fontforge.sourceforge.net/gposgsub.html#not-converted
) mentions some contextual substitutions that "cannot be expressed
in Apple's state machines". I agree that they cannot be expressed in a
single AAT state machine. However, they can be expressed in a sequence
of two AAT state machines if an invalid glyph number (a glyph number
that does not correspond to any actual glyph in the font) is passed on
from the first state machine to the second as a kind of variable.
According to the Apple Font Tool Suite Tutorial (the one that comes
with an installation of version 3.1.0 of Apple’s Font Tools, not the
one that is available on the internet at Apple’s developer site), this
trick is possible because: "The ‘morx’ parsing engine doesn’t see
glyphs ID’s as anything but numbers; it never checks to see if they
are valid or not. So long as what gets handed off to render consists
of valid glyph ID’s, you can put invalid intermediates in."
I am adding a simple example font, "morxTestcase.ttf" along with the
Morph Input File I used to create that font. In this font, the input
character sequence "a b c d" will produce "a B C d" as in an example
said not to be convertable in the mentioned section of FontForge
documentation. In a first AAT state machine, the sequence "a b c d" is
converted into "a b 2010 d". 2010 is just a random invalid glyph
number I picked. In a second AAT state machine, the sequence "a b
2010" is converted into "a B C", and any other occurence of "2010" is
converted back into "c". That's it.
I admit this is not very elegant, since it requires two state
machines. However, it proves that Apple's state machines can do the
job. Therefore, the statement in the documentation is misleading. I
imagine that this entire procedure might be automated, so I guess
theoretically nothing would bar FontForge from implementing it in the