At 10:24 5/29/2002, John H. Jenkins wrote:
>>In particular, I think it is is mistake to resolve display of
>>character-level decompositions by relying on the presence of glyph-space
>>substitution or positioning features in fonts, simply because most users
>>have very few fonts that are capable of doing this.
>
>Agreement; Apple's current solution is a "better-than-nothing" one, but
>not really what's best in the long run IMHO. BTW, does FontLab 4
>auto-generate OT layout data from the Unicode repertoire of a font?
It could be made to fairly easily using existing functions and Python
scripting, but it isn't a built-in automatic feature.
There are, however, architectural reasons why some layout data that you are
putting into AAT fonts is deliberately absent from OpenType. There are
currently no OpenType features for specifically handling canonical
composition or decomposition of glyphs representing Unicode strings*, and I
don't think such features would get very far if one proposed them to
Microsoft and Adobe. OpenType tries to maintain a clear distinction between
what should be handled in character space and what should be handled in
glyph space, whereas AAT is content to handle pretty much everything in
glyph space. The impression I have from discussions with people in the type
groups at Microsoft and Adobe is that they are agreed that canonical
decomposition and its resolution for display is something that should
happen at the character level, prior to any glyph processing. Because of
the architectual principles of OpenType, Apple's 'better-than-nothing'
approach as you describe it, would more likely be seen as 'nothing is
better'. I get the impression than Apple are willing to release temporary
measures while working on better long term solutions, while Microsoft
prefer to wait until the long term solution is ready. Either approach can
be valid, but Apple's is facilitated in this instance by the fact that they
have a font architecture in which doing character level processing in glyph
space is acceptable.
* OpenType has a slightly misnamed Character Composition/Decomposition
<ccmp> feature (it is actually a glyph composition/decomposition feature),
which enables font developers to make decisions about how best to handle
display of individual typeforms. But this is not limited to, or even
appropriate for, resolving canonical character decomposition, since it can
be used to decompose or compose any glyph in a font. In a single font, this
feature might be used to compose some glyphs (e.g. representing the Hebrew
hataf qamats and meteg marks as a single glyph) and decompose others (e.g.
decomposing the Arabic alif with hamza in order to take advantage of
coloured diacritic marks in Word).
John Hudson
Tiro Typeworks www.tiro.com
Vancouver, BC tiro@tiro.com
When the pages of books fall in fiery scraps
Onto smashed leaves and twisted metal,
The tree of good and evil is stripped bare.
- Czeslaw Milosz
This archive was generated by hypermail 2.1.2 : Wed May 29 2002 - 12:49:32 EDT