This is an interesting topic for me too and I'll be watching it with a great interest.
From my experience, you can put AAT and OT into a single font. But the applications choose one or the other. In other words, you have to put GSUB for OT and duplicate the same functionality in MIF for AAT.
This is what I was doing for quite a while now because for a single Arabic font that you want to use in a workflow, exporting from Illustrator to FinalCut for example, this is -not a perfect way- but the only way to make it work.
But this is a lot of work and a lot of duplications in making a font and still it doesn't always work as intended. I love to know if there is a possibility for Mac text engine, that when AAT is engaged, it also borrow some features of OT at the same time, or vice versa.
But my experience was either this or that.

behnam writes:

This is what I was doing for quite a while now because for a single Arabic font that you want to use in a workflow, exporting from Illustrator to FinalCut for example, this is -not a perfect way- but the only way to make it work.

I don't actually know Arabic, so I might be wrong here, but Adobe Arabic appears to work fine for me in TextEdit. In Tiger (or perhaps I'm thinking of Panther) .otf Arabic fonts definitely didn't work in AAT, but Leopard seems to support them. So at least for Arabic, one could just use OT features provided you didn't mind requiring your font's users to have OS 10.5 or greater. The general problem, though is definitely still there (e.g. I don't think AAT can deal with Indic languages unless a morx table is present).

Even without dealing with multiple script systems, though, the set of behaviours which can be implemented under AAT and OT are not identical, so there may be cases where one would like to implement a feature in one system and then approximate it as closely as possible in the other to maximize the number of applications which can effectively make use of glyph alternates, etc. which are present in the font.

André

Yes indeed. Leopard has completed its OT support for Arabic. But it is not yet completely spread throughout the Apple applications. FinalCut and Motion, among others, still need AAT.
At some point they will all take advantage of Leopard OT support for Arabic but it's not done yet. Just a couple of weeks ago, BBC World Service asked me to put AAT to their newly purchased Persian font. It was not working with their FinalCut for their Persian TV production.
The core of Mac text engine remains AAT. NeoOffice which uses Leopard engine, can easily use Arabic OT fonts for the body text. But we noticed few days ago that its localization for Persian (and surely for all Arabic script) has some designated OT fonts (Arial, Tahoma, Courier New etc.) which don't work on Leopard for Arabic rendering and they don't show properly in application menus etc.
You are absolutely right. For basic behaviour there is no problem. But for the typographic side of it, I only can approximate one to another.

AFAIR, the problem is that in Mac OS X 10.4 Tiger, if a font has both OpenType Layout tables (GSUB/GPOS) and AAT tables (morx etc.), the OpenType Layout tables will always be used and the AAT tables will be ignored. In Mac OS X 10.5 this may have been changed, but I don't have time to check it now.

This is why SIL developed two separate versions of their Arabic fonts Sheherezade and Lateef, one for OpenType Layout applications and one for AAT applications. They differ in family naming so both can be installed at the same time (e.g. one for TextEdit, the other for InDesign Middle East).

http://scripts.sil.org/FontDownloads

A.

> Leopard has completed its OT support for Arabic

Well, not really "completed" -- much rather implemented a first version. But OpenType Layout-based Arabic support only works in the new CoreText API (first introduced in Tiger), not in the old QuickDraw and ATSUI APIs that many applications still use. For all other complex scripts such as Devanagari, AAT is still the only solution.

To underline what I've written before: in Mac OS X 10.4, if you put Arabic or Indic AAT and OpenType Layout tables, then the system will recognize the presence of OpenType Layout tables and will ignore the AAT tables, but since it cannot process the complex-script OpenType Layout shaping for those tables, in the end nothing will work properly.

Adam

Yes that bug existed with Tiger and the AAT component of my fonts were ignored. But it has been fixed since version 10.4.2 or so and if a font has both, AAT gets the priority. This was very important with Tiger that it's OT support didn't include 'init', 'medi' and 'fina' tables. With 10.5 the problem is not as serious. If AAT in ignored, OT can still do the job. The problem remains though, with some Apple applications. Motion seems to be one of them. My dual identity font for BBC although solved their problem with FinalCut, but I had to produce an AAT only version to work with Motion.
But as I mentioned and Adam confirmed, for core processing, such as localization, still AAT rules.
SIL solution is a safe bet. But it's the workflow that is sacrificed in this whole technology conflict.