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: <[EMAIL PROTECTED]>
