On 03/06/2002 04:57:07 PM Yaap Raaf wrote:
>I have the impression that somehow AAT fonts are less dependent on
>ATSUI than OT fonts are on Uniscribe. In fact I am a bit amazed that
>with all the tables and 'intelligence' built into OT fonts they are so
>dependent on updates of Uniscribe. I do not hear about updates of
>ATSUI. Are there fundamental differences between ATSUI and Uniscribe?
You have to compare ATSUI/AAT with Uniscribe/OT. Each pair does two
things: provide a set of APIs for applications to use to manage line and
paragraph layout; and do the character <> glyph transformations needed for
complex script support and fine typography (as well as UI issues like hit
testing). But, there is a very big difference in the division of labour
used by each pair.
Uniscribe provides APIs, and also performs some of the script-specific
transformations that need to occur in mapping from characters to glyphs.
In prinicple, it embodies knowledge that is true for a given script
independent of any particular font implementations. So, for example,
Uniscribe handles re-ordering of Indic vowels, "flying ra" and things of
the like -- any reordering of glyphs (including the bidi algorithm) is
done here; it also handles identifying word positions / connecting
contexts for Arabic glyphs. It deals with behaviours of this sort that
apply to a script regardless of what particular glyphs are involved. It
then turns on "features" to indicate contexts requiring glyph-specific
behaviours (e.g. word-initial / left-connecting glyphs), and passes on the
string of feature-tagged glyphs to OpenType. OT then looksup rules in the
font to do whatever substitutions or positioning are needed. OT deals with
whatever is dependent on the particular glyphs that are used in a font.
The ATSUI/AAT model is quite different. ATSUI provides APIs (for many text
processes, not just rendering), but all script-related behaviours are
handled by AAT. AAT has a generalised engine for processing
character<>glyph transformations, and all the specific details regarding a
given script and the font-particular implementation choices are embodied
within the font in the form of state machine transition tables. So, the
generalised engine is what interprets and processes those state machine
descriptions in the font.
So, whereas things like Indic reordering or Arabic contextualisation is
handled external to the font in the Uniscribe/OT model, everything
script-related is encapsulated inside an AAT font.
Graphite is quite similar to AAT in that all script-related behaviour is
encapsulated within a font. They differ in some technical details with
respect to what mechanisms they use to handle script behaviours (e.g. AAT
supports glyph ductility but not attachment points; the opposite is true
for Graphite). The biggest difference between AAT and Graphite has to do
with tools for creating the state tables: for AAT, you basically have to
write tables directly by hand, whereas Graphite includes a high-level
description language, "GDL", for describing the character<>glyph
transformations.
You can find a good overview of Uniscribe/OT written by our esteemed list
member and type designer John Hudson at
http://www.microsoft.com/typography/developers/opentype/default.htm.
There's a overview of Graphite available at
http://graphite.sil.org/pdf/IUC17_paper.pdf. There isn't a good overview
of AAT that I know of; the best resource I can point you to is a slightly
dated technical comparison of AAT (actually, it's precursor TrueTypeGX)
and OpenType, at
http://developer.apple.com/fonts/WhitePapers/GXvsOTLayout.html.
That paper comparing AAT and OT brings out an interesting point: the
OpenType specification did *not* create a standard for how to implement
script support in fonts; it just provided mechanisms for storing and
retrieving glyph-processing information in a font. The standard for
implementing script support in OT has been in the process of definition
more recently as Uniscribe has evolved. Thus, it's really Uniscribe that
determines how OT fonts get implemented. When developing AAT or Graphite
fonts, you are taking Unicode character* strings as your input and
processing in terms of that. When developing OT fonts, however, your input
isn't Unicode, but rather it's the output of Uniscribe: transformed
Unicode characters* marked up with certain feature tags.
*OT, AAT and Graphite rules deal entirely with glyphs, not characters, but
the initial glyphs are those mapped 1:1 from Unicode per the font
developers choice as specified in a "cmap" table.
>I would think that once Uniscribe has the capacity to process Arabic
>and Devanagari it could manage about everything any complex font will
>ask for.
In a general sense, yes. But it doesn't work on generalised processing
with all script-specific details in the font.
>Certainly something like combining combining marks with base
>characters, provided the information for where exactly they have to go,
>will be present in the font.
Indeed they are. The problem is, the OT layout engine won't look at the
rules for positioning combining marks unless the appropriate "features"
are turned on by client software. Every OT rule in a font has to be
accessed via some feature, and something external to OT has to activate
that feature. Unscribe does that. (An application can also do that, but at
this point none do.) And if Uniscribe hasn't yet been written to turn on
features needed for dealing with a particular script behaviour (such as
positioning of combining marks on Latin base characters or for stacking of
combining marks), then that behaviour is not available.
>But this seems to be something for a rather
>distant future.
Not so terribly distant. The engineers working on Uniscribe have been
making steady progress, though I think it takes a while before
improvements get incorporated into updates of any shipping product. I can
easily imagine, for example, the IE team saying, "We're happy that you've
got a new version that handles such-and-such behaviours, but we haven't
tested whether our code can live with those behaviours, so we're sticking
with the same version we're using now."
>Making Unicode keyboards was "something of a black art on the Mac"
>almost a year ago. Does this still hold?
It can be done if you know what your doing, but there aren't any
particular tools to help. I guess that means "yes".
- Peter
---------------------------------------------------------------------------
Peter Constable
Non-Roman Script Initiative, SIL International
7500 W. Camp Wisdom Rd., Dallas, TX 75236, USA
Tel: +1 972 708 7485
E-mail: <peter_constable@sil.org>
This archive was generated by hypermail 2.1.2 : Thu Mar 07 2002 - 06:40:26 EST