John,
Let me add a few more points to John Jenkins' comment.
As John mentioned, we're working on to add the character space
processing capability to the OS. In fact, Cocoa framework, one of the
two primary APIs in Mac OS X, can already handle most of the combining
marks pretty reasonably well without the help from AAT tables.
Please note neither glyph space only nor character space only solution
cannot fully embrace the flexibility of Unicode. It needs to be
hybrid. By being glyph space only solution, you lose the character
semantics defined in Unicode in typesetting. Whereas, by being
character space only solution (meaning applying NFC before rendering),
you cannot render arbitrary sequences of composed characters allowed by
Unicode.
As the Cocoa framework currently does, you could position combining
characters without precomposition by just looking at the combining class
for most cases. However, it's still desirable fonts to have positioning
information for better typographical result since the font designers
themselves know best about glyphs they're designing.
Aki
On 2002.05.29, at 11:29, John Hudson wrote:
> 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 - 14:02:35 EDT