Mailing Lists: Apple Mailing Lists

Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Leopard, ATSUI and contextual forms in OpenType fonts



Yeah, people are happily surprised at the ease of the transitioning from ATSUI to CoreText once they dig into it. Both have similar objects but in general, quite a bit of code can be eliminated by switching to CoreText. It's just a cleaner API for MacOS X. And of course you get the added benefit of nearly doubling your layout and rendering performance while integrating way better with our other frameworks.

Where did you read on the web web about the reversed table precedence? It is true we favored AAT in the first release of Tiger but, we issued an SU soon after to reverse it to the way it is now in Leopard after we realized our error jumping the gun with OpenType.

Sorry about your troubles converting your font. I should get you some help on that within the next few days.

Dan


On Nov 1, 2007, at 11:04 AM, Jerry wrote:

Hi,

Thanks for the help.

Having looked at it a bit more, it looks as though we could switch to Core Text quite easily. I've written some code, but I've run into a load of other issues which prevent me from testing it - I have to switch to the 10.5 SDK to use the Core Text framework and now I have to fix 20000 compilation errors due to the definition of uint32 being changed, which conflicts with Adobe SDK and libtiff headers. This may take some time....

I read somewhere today on the Web that OpenType tables take precedence over AAT tables, which was why I was trying to delete the GSUB table.

As for converting the fonts: I'll explain a little more what the problems are:

Firstly, ftxanalyzer is supposed to write out a MIF file that ftxenhancer can read, but it doesn't. Instead you have to go through with a text editor fixing it up - e.g. replacing Unicode names by U +xxxx code points. I tried useing ftxanalyzer -U to give me the universal magic MIF, which I believe might contain the Arabic contextual form stuff, but it has no effect. I'm using MorxTester to test the results. I've tried creating a simple MIF file which has a ligature in it, and that worked, so I know the 'morx' table is there and being read.

Jerry

On 1 Nov 2007, at 17:29, Daniel Fenwick wrote:

ATSUI is still a powerful layout engine albeit from an AAT font table standpoint. How the font table precedence works is if a font has a 'mort' or 'morx' table in it, ATSUI and CoreText will do the layout using AAT whether or not the font also contains OpenType tables. This is because at present, MacOS X still has more complete support for AAT than for OpenType though this is rapidly changing as we add more OT shaping engines to CoreText. There is one caveat to this precedence and that is, if the font does not have a 'mort' or 'morx' but does have a 'GSUB', both ATSUI and CoreText will do what they can using the 'GSUB' table but if the font also has a 'kern' table, ATSUI and CoreText will use that instead of the 'GPOS' table (this is actually part of the OT spec which might help you somewhat in this instance).

So the bottom line is, try to use CoreText moving forward in your development; it will continue to get better and better OT layout support with each upgrade to MacOS X. CoreText also has nearly all the support for AAT table layout that ATSUI has (only the very obscure AAT stuff is missing that nearly no one notices). If you need to use ATSUI for the time being, try to rely upon AAT font usage and converting your OT fonts to AAT during this transition is probably the best solution (I'm not familiar enough with those tools you mentioned so I'll forward your email to some people who are).

Dan

On Nov 1, 2007, at 9:42 AM, Jerry wrote:

Hi,

Thanks for the helpful reply.

After more investigation, it turns out that it does work with Core Text - I'd managed to get the font system confused by attempting to use the Apple font tools to create 'morx' tables for the fonts (with no success). Converting our app to use Core Text probably won't be trivial: we're getting the glyph outlines directly to do our own font rendering. I think I can maybe do it by leaving all the rest of our ATSUI code in place, and then creating a CTFont from the ATSFontRef we have.

A better solution in the short term would be for us to be able to convert the problematic fonts: there are only a few of them, and converting them would keep our customers quiet until we can spend the time to do the Core Text conversion. I've tried using ftxanalyzer and ftxenhancer to create a morx table for the fonts, adding the "magic universal MIF" and the MIF from a working TrueType Arabic font, but to no effect. I've tried removing the GSUB/GPOS/GDEF tables from the font in case they are taking precedence, but that doesn't work either. Am I barking up the wrong tree with this, or could this actually work?

Jerry

On 1 Nov 2007, at 15:49, Daniel Fenwick wrote:

Well, first off, ATSUI, and MLTE which uses ATSUI, does not support the OpenType Arabic shaping engine (it would have been great to get into ATSUI for Leopard but... as I explained at the last WWDC, ATSUI is actually a very old technology that is getting very difficult to shim new technology into so we are strongly advocating developers use Cocoa and/or CoreText moving forward). The TextEdit app as you noted does do OpenType Arabic shaping which is done solely through CoreText. So really CoreText is the ticket here and can be used in a Carbon or Cocoa app (it has toll free bridgeable objects with NS). It also will retrieve the glyph outlines which was a developer request at WWDC '07 that allowed more apps to switch from ATSUI.

So I surprised your layout is not working with CoreText. Could you please send me some example code and the font that you are relying upon? It should definitely work if it works in TextEdit and I've tested very complicated Arabic OpenType fonts using CoreText with positive results.

Dan Fenwick

On Nov 1, 2007, at 5:58 AM, Jerry wrote:

We have customers who are using OpenType Arabic fonts, but find that the contextual form substitution does not happen on the Mac. This is because OS X didn't support the OpenType tables which do the substitution. When I asked about this on this lists previously, I was told that full support would be in Leopard. Well, Leopard has arrived, and the customers are complaining already. It seems that these fonts now work correctly in TextEdit, but nowhere else. I've tried using them in MLTE, ATSUI code and Core Text code and have been unable to get contextual forms to work. I've also tried using ftxanalyzer/ftxenhancer to create 'morx' tables for the fonts with no success. I've tried turning on every typographical feature I can think of in ATSUI to no effect.

Does anyone have any ideas on this? Since the fonts now work correctly in Leopard's TextEdit, OS X can do it, but how do I draw Arabic text in my Carbon application with contextual form substitution? (Creating an offscreen NSTextView is not an option as we need to do our own font rendering using glyph outlines, currently obtained from ATSUI).

Jerry




_______________________________________________ Do not post admin requests to the list. They will be ignored. Carbon-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/carbon-dev/email@hidden

This email sent to email@hidden
References: 
 >Leopard, ATSUI and contextual forms in OpenType fonts (From: Jerry <email@hidden>)
 >Re: Leopard, ATSUI and contextual forms in OpenType fonts (From: Daniel Fenwick <email@hidden>)
 >Re: Leopard, ATSUI and contextual forms in OpenType fonts (From: Daniel Fenwick <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.