Tiger kills AAT!

behnam's picture

Mac OS 10.4 now translates some OpenType features into its AAT environment but not all of them. Notably contextual features are missing. So any .otf or .ttf with OT enhancement for languages such as Arabic are still unusable on Tiger because contextual features are vital for such languages.
I made some fonts that have both OT and AAT features to be compatible with any environment. Now with Tiger, the presence of OT features in these fonts results in partial translation of those features in AAT and ignoring the pre-existing AAT features of the font - including their contextual AAT features!
If you plan to add AAT to an OT font, beware of this problem. It will be useless.
All Apple has to do is to add a command in its text engine that 'if AAT detected in the font, ignore OT'. I know it's easier said than done but this shouldn't be too complicated.

John Hudson's picture

Good to know.

Note that OT fonts for Arabic do not need contextual lookups for basic language shaping -- although AAT does --: OT works on the basis that an Arabic layout engine will apply the and features appropriately based on character-level analysis of text strings.

behnam's picture

That would be Uniscribe or WinSoft I suppose?
But the result is the same. Those Arabic engines are not transllated and applied in AAT environment and the Arabic font with OT features won't work on Tiger.
And it kills the existing AAT features all the same.

capthaddock's picture

File a bug report with Apple. If you don't know how, give me the relevant information, and I'll do it.

behnam's picture

I'm in the process of gathering more information about what exactly Tiger is doing with OT/AAT fonts. But I already reported to Apple feedback the issue and I don't think I can get much more detail because essentially the problem is that Tiger doesn't give priority to AAT for such fonts. So there is nothing left to look at... at least not on AAT side.

capthaddock's picture

Feedback is fine, but I still think that if you file a bug report at the developers' site, Apple will be forced to analyze the bug and assign it some kind of priority for fixing.

John Hudson's picture

I've alerted the OpenType discussion list, to which Peter Lofting and John Jenkins from Apple subscribe. I'm sure they'll take note, not least because people have been having a laugh at Apple's expense. I particularly liked Steve Hartwell's adaptation of Winston Churchill's comment about Americans: '[Apple] will always do the right thing, but only after having exhausted every other possibility'.

behnam's picture

Maybe you should file a report at the developers' site on my behalf capthaddock. I don't know how to do it. And I'm not a developer really.
All you have to report is that Tiger doesn't give priority to AAT for OT/AAT fonts and it disregards entirely AAT features of the fonts and in this process it makes them dysfunctional because contextual features of OT are not supported either.

And thanks John for your post in OpenType discussion list. A friend of mine sent me the thread. It was very informative and amusing. I also enjoyed Churchill's quote a lot!
This whole thing must be an embarrassing overlook by Apple otherwise it just doesn't make any sense.
They could have all the OT features they could handle in OT only fonts without sacrificing AAT of OT/AAT fonts.

Thomas Phinney's picture

Apple is (and already was) aware of the problem. I don't know that they overlooked it. It's just that the OpenType support in OS X is in its early days yet. Things will doubtless improve over the next few years, just as they have with OS X Unicode support.

Hybrid AAT/OT fonts were always a high-risk approach to take - it's unfortunate but almost inevitable that there would be some problems as soon as you hit an environment that supports both.

Regards,

T

behnam's picture

If Apple knew it and did nothing then it's a real catastrophy. I'm not sure if the term 'hybrid' is justified in this case. The AAT components of an AAT/OT font doesn't intervene with the OT component of it as far as I know. I can easily open my AAT/OT font in FontLab and delete all its OT features and generate a font which is perfectly capable of running on TextEdit. Do I need to do that? Is it so difficult for Apple to simply ignore OT in it's own environment?
AAT/OT fonts for some languages like Persian or any other language of Arabic script is not a fancy supposition. It's bear minimum for cross platform compatibility. How Apple could ignore it in an evolution which incidently was born with cross platform compatibility in mind?!
Apple runs AAT fonts as good as ever. Can't it 'identify' an AAT/OT font as an AAT font and do the same thing?
Regards

Thomas Phinney's picture

Whichever way they do it, as soon as you have an environment that supports both, some things can go wrong. What if I were to take a fancy OT font, and add some basic AAT functionality to it? If AAT features take precedence, then the greater bulk of the functionality would be lost.

In this case, the OS can do more with one format than the other. So the "right" behavior is more apparent. But there's always the danger, or even likelihood, of fonts implementing one path more than the other, or worse just having some slightly different effects depending on whether one treats them as AAT or OT. There will be problems with hybrid fonts, it's just a question of degree and what those problems are.

T

behnam's picture

You are absolutely right.
As a matter of fact, the behavior of my OT/AAT font is slightly different depending on whether it's used in AAT or OT environment. These differences could be more pronounced if I wanted to (and could!) produce a font with more 'fancy' components and sophisticated presentation. Dual technology for text presentation is inherently inconsistent but this is not about a choice between AAT or OT. It's about having or not having cross platform compatibility.
I'm talking about bear minimum requirements for a Persian font to be able to be useable in both platform. This is what essentially I put in my OT/AAT font and slight differences of font behavior in each environment is not a major concern. The concern is having a readable text in both environment or not having it at all. And I think facing this reality, the choice of Apple about which part of an OT/AAT font should be sacrificed in favor of the other is rather clear.
Sometimes it's hard to describe how this can be important to those who don't use the concerned languages. But to give you an idea I give you a recurring problem for Mac users on Safari.
If Mac users had installed MS Office for Mac, they have installed along Times New Roman and Arial of MS which cover Arabic script.
Now, many web-pages in that script are designed on PC and frequently TNR and/or Arial are tagged in their page layout. So Safari opens those pages with these fonts... with broken characters because they don't have AAT! The only choice for Mac users is to delete their fonts to be able to view those pages properly!
If those pages were tagged with an OT/AAT font, users on any platform would not have such problem, whether they had those fonts installed or not.

mike victor's picture

I have a lot of problems trying to use LinoType Sabon Next. The only way I can use small caps is to disable all other Sabon Next fonts, and even then the font menus don't always show the correct name. ("Bold SC" shows simply as "Bold"). If I use the small caps feature in Adobe CS2 (all of the apps) I get the faux small caps, not the open type versions. Could this be a related problem?

Mark Simonson's picture

Could this be a related problem?

Not likely. I don't think Linotype Sabon Next or any Linotype fonts are available in a format that includes support for both AAT and OpenType. Most likely, it is a naming issue. Your best bet would be to contact Linotype support.

Syndicate content Syndicate content