Hello and welcome to Session 136, Modernizing Your Text Rendering With Core Text. Thanks for coming. I'm sure a lot of you are coming from the Quick Draw and ATSUI stance of dealing with Unicode text and non Unicode text, so hopefully this session will help you out in your development moves as we go forward on Leopard. The main things we'll be talking about here in this session is Quick Draw text and ATSUI and how they compare to our newest member of the Mac OS X text handling API, Core Text.

And I hope by the end of this session you'll have even more reasons of why you'd want to make the switch to using Core Text. So what I'll be covering is first a brief tour of the Leopard text system. And some of the major changes within the system as it pertains to Core Text usage.

And then throughout the talk I'll be of course discussing Unicode, because of course Core Text and Cocoa, for that matter, is based on Unicode Text. And just to drive home the importance of Unicode, it's throughout the entire text world, including Core Text. So with that I'd also be talking about the main points, which is Quick Draw text and ATSUI.

In particular, I'm going to touch on some string input and storage methods and calls you can make and string conversions that I'm sure some of you would need to be making from your older applications into our modern string packages, in particular CF string into CF attributed string packages.

And then font references. A lot of you have expressed confusion over all of our font references. We have a slew of them and Core Text is actually adding two more, the CT font ref and the CT font descriptor ref. but with these references, it actually should clean up how you look at defining your fonts in your application, which I'll touch on to later specifically. And then measuring line breaking and rendering will all be looked at as a unit with examples in Quick Draw, ATSUI and comparing to Core Text and give you an idea of the quickest path to updating your application.

And lastly, I'll touch on the fonts window, our fonts panel, as some people refer to it. This was also covered in the Core Text talk earlier this morning. There's a great example application that I really want to advocate you taking a look at. Some great stuff in there.

Something, a particular note in this regard is handling the fonts window and how easy it is now using Core Text. So what's new in text? Core Text, but actually Core Text isn't new. It's in Tiger, but used under the covers pretty much all by App Kit. It was created specifically for App Kit at that time to give it an alternative to its core layout needs to ATSUI.

Now why would you want to move off ATSUI? Well, we'll touch on that later. One of the main reasons was ATSUI started getting stuck in the mud in terms of progressing its functionality and it's performance was reaching an asymptotic point at which it could just not get any more fast.

So it's a proven technology that's Unicode based, of course, like all of our new APIs for text handling. And it's built as a Core Foundation object. So you get all the benefits of handling a Core Foundation object, such as the retain and releases and full thread safety that you'd expect from Core Foundation.

And it's also built with solid Quartz and Cocoa integration, unlike Quick Draw and ATSUI for instance, Core Text was built after Mac OS X was released, and so it's main output, of course, is through Quartz. And Cocoa, being our main API that we are advocating usage of, the reason really is better text handling and performance, needed to be integrated with Core Text in such a way to maintain it's optimal performance. So you get exceptionally fast text layout by using Core Text that you can't obtain using our other APIs, especially on Carbon.

It's very easy to optimize, so unlike ATSUI, for instance, that gets a little mysterious on how you should optimize your output, say should you keep a style object, should you throw it away, should you set an attribute, or what order are you going to be making these API calls? Core Text is a lot more straight forward in understanding how to make it as fast as possible.

So with that, it's also simple and intuitive to use and of course it's 64 bit ready in a Cocoa framework. So the main changes in text support in Leopard that I just wanted list here, is that App Kit has made the switch to Core Text exclusively. Before, in Tiger was holding off complete usage of Core Text for doing certain things like accent attachments and what not. Now it can use Core Text exclusively. It's got the performance obtained by using Core Text and it's all very happy. But not to be left out of the game, HI Toolbox also started using Core Text for it's static text and its font fallbacks.

Now once HI Toolbox started using the font fallbacks, this domino effect started occurring. Well hey, now ATSUI looks a little bit different than what HI Toolbox is putting out, so we have now ATSUI using Core Text for it's font fallbacks. Now what's so great about these font fallbacks that we felt a need to switch? And the reasons is because now the font fallbacks more closely match what your original font you assigned to your text is, so it matches traits such as serifs and stuff like that and whether it's bold or not, more accurately so you get a more seamless appearance across your line.

This is really a great thing and if you've been frustrated with font fallbacks before, trying to adjust them to your own needs, just to get around this little inconsistency, or big inconsistency, depending on where you're coming from, I think you'll really enjoy the new font fallback scheme introduced by Core Text. So this is the Leopard text system in the nut shell. Over in the big green box is the Carbon text side of things. MLET is still calling into ATSUI for it's text editing.

And then there's Quick Draw text of course, calling into ATS to get it's curves and bitmaps and stuff. ATSUI now though in Leopard is calling into Core Text, as I mentioned, for it's font fallbacks. There's also a few other things it's calling into, but more and more it's moving over to rely on Core Text for it's basic needs. And of course Cocoa, as I mentioned, is now using Core Text for all it's layout needs. But I'm sure doing a lot of other work besides that for text rendering, but for it's main layout engine it's using Core Text.

And I just wanted to list here our current font references on Leopard. A lot of you are familiar with the classic references, of course, the ATSUI font, the FM font, font family, and ATS font family references. These were all great in their day, but as time moved on we had to keep on adding references in order to address the technology shift in fonts that I'm sure all of you are aware of.

Fonts are getting increasingly complicated and sophisticated and I think that's great. I mean, text has never had such a boom in usage these days, so I'm really looking forward to moving on to the modern APIs and modern font references that can be found from the NS font in NS font descriptor.

The great thing about Core Font descriptors is that they're toll free bridgeable with the NS equivalent. So you can go ahead and interchange these within the API calls. That's really a boom and I think you'll get a kick out of being able to swap one for the other.

So let' move on to Quick Draw. And for those of you who have never stepped into a Quick Draw editing session, maybe you can check your emails or whatever, but keep an ear open, maybe we can touch on something that you can look into further later. First, I should say, Quick Draw is dead. I'll say that right now.

This is probably the last time you'll even hear about Quick Draw at a WWDC. So in that sense, you're sitting in on some history right here at WWDC. Quick Draw really had an amazing run. It served an incredible amount of developers and it was the only way to draw and render text on the system.

It's been in use just way longer than we ever though possible, only because it was worked on so well by all our engineers keeping it alive through these years. But support is diminishing now and it is deprecated, by the way, so it's really time to move on to something else. And something else, I'm happy to say, is Core Text.

Because in the older days, really international text was a hag. If you can remember when Quick Draw needed to now introduce what's called World Script in order to do the more complex scripts, we kept on hacking on to Quick Draw in order to make it handle more and more complex situations. So now with the introduction of Unicode, as we'll talk about later, we can get away from all these hacks.

So let me list some of the reasons why you'd want to change from Quick Draw, if you aren't convinced at this point. First of all, Quick Draw is deprecated and with any deprecated API there are dangers to using it. I'm not saying it's going to be pulled out from under you, but any further development, don't expect any new APIs to come out of Quick Draw and some bugs will probably remain forever in Quick Draw now. Not because we just hate Quick Draw developers, but because now developers are depending on those bugs. They built around them, if you change them, you've really screwed these people. So we're very cognoscente about that.

So by at least deprecating it it has signaled that it's days are definitely numbered and you shouldn't use it. And the main reason is that it's not Unicode based. World Script One, by the way, isn't even supported in Mac OS X. so don't expect to do Arabic rearrangement or anything like that with Quick Draw. It's very much a part of the past and I will emphasize this over and over again, and add nauseum, I'm sure, but I just want to impress upon you that you can't do these complex scripts anymore using Quick Draw text.

Now for instance of some of it's incompatibility with the current graphics system is how it does its sub pixel rendering. In fact, it doesn't do sub pixel rendering unless you can use some of the special attributes that were developed to kind of shim it into the Quartz environment. So on the left here, this is how Quick Draw would normally render text, meaning all the glyphs are entered on an integer origin basis and so you might end up with kind of awkward spacing.

I know you've seen the old picket fence example of a slew of L's and having some of the L's closer or further apart, that's due to the fractional rounding involved in order to make all the glyphs land on integers. And the anti-aliasing itself is much deeper and richer in a full Quartz rendering system using colors, for instance to simulate a fractional bounds in which to lay your glyphs out.

And believe it or not, using Quick Draw can actually bog down the overall system performance. Every Quick Draw call calls into FM swap font, and FM swap font could, by nature of calling to ATS for its information, could actually generate a width table generation that would swap it's caches and what not.

Now this uses up a lot of cycles, of course, in the ATS server that other processes are using. And it will also slow down your own process in the process. So I just want to emphasize that it's not efficient to use quick draw for this one reason right here.

And of course it doesn't play well with the other frameworks, in particular Cocoa. Don't expect to make a viable Quick Draw App using Cocoa objects. Now this last reason is kind of near to my heart because I work and concentrate on the typography on a system, and Quick Draw can't access all the advanced typography features that are now available in most fonts, such as ligatures, in a simple case. Here, on the Zaphino font that comes on the system, you can create a single ligatured glyph from the character Zaphino. And then I also list a (inaudible) example here of rearrangements and insertions.

Now why stay with Quick Draw? I really search for reasons why you'd want to stay with Quick Draw. I only came up with one, and that was your app uses bitmap only NFMT fonts and you can't switch from using that particular font. It's an app specific thing and you just can't move from it. Well, we don't advocate using bitmap only NFMT fonts anyway.

Those in themselves are deprecated. So try not to use those fonts, they're very limited and clunky looking first off. But if you are in a situation where you have to use that, that would be a viable reason why you'd want to stick with your current code base. The other reason, of course, is that you're out of business so it doesn't make any sense to upgrade any way.

So there's choices. Not a lot of choices for you, but there are choices. They aren't admittedly pretty, because when you're dealing with Quick Draw, you're in a totally different realm of how to deal with Unicode text. You're on a run basis, you need to keep a lot of things up in the air in order to do correct international text, which I'll touch on to later in the presentation.

So the ultimate would be to rewrite your application using Cocoa. That's the ultimate. And I'm not just saying that as a buzz here. I really think that you would be best served by switching to Cocoa. Now you can still use Core Text within your Cocoa app for any fine adjustments such as what was brought up in the Cocoa presentation here, vertical text. But I highly advocate you start adopting Cocoa for your text.

Now you could just stay in Carbon and use Core Text. It's incredibly powerful. It can basically do everything that ATSUI can render, at least, and so you might be perfectly happy staying within a Carbon framework and using Core Text. And then lastly, at least, keep on using Unicode, or use Unicode text in your application and use ATSUI. And I'll give some instances to why you'd want to use ATSUI over Core Text, but there's not a whole lot, but at least you're using Unicode text when you're using ATSUI.

So for those of you that know Unicode like the back of your hand and everything, this may be rehashed, but just let me go over some key points about Unicode that make it so important and make it the standard in the world for text. Unicode fonts have greater coverage, much greater coverage. So your extender Roman, Greek and Cyrillic are all within our Core Fonts on the system. And CGK text just wouldn't be able to be addressed in the modern world without Unicode text.

All the new text APIs on the system use Unicode. There's just no other reason to go back to the old script basis of organizing your text. Unicode is an established standard that Mac OS X uses, so all the new APIs are designed around that. If you want the latest and the greatest moving forward, then Unicode's the way to go.

And there's nearly 100,000 characters available in Unicode that's being mapped. That's Unicode 5.0 now and 5.1 should tip it right over 100,000 characters, now that's more than just mapping characters, of course. Unicode sets the layout rules for each language within this mapping on how to rearrange, how to layout the text correctly and all the properties assigned to every single character are defined. If you don't believe me, just pick up yourself a good Unicode 5.0 book and get a good work out lifting that thing, because it's got everything in is. It's really fascinating looking through this book on all that Unicode has brought together for text.

And I bring up UTF 16 processing because that is the main atom that Core Text uses internally. It's a 2 byte unsigned quantity for defining the Unicode character code point. It's not one to one, like in the Quick Draw days where you'd expect a single glyph represented from a single character. You could end up with many more characters than you originally put on by insertion properties, you'd actually end up with extra glyphs. You could also consolidate your characters into single glyphs, like I was showing before with the Zaphino example.

And in this case, I'm combining and E with an acute accent to an E acute character. So don't think one to one anymore in a Quick Draw space. I know a lot of you have already moved off of thinking that way. I just want to drill that point through because it still trips a few people up Now text input, you've got choices on that front too. And from the Carbon viewpoint you have the HI text view, the MLTE for text editing. And on the Cocoa side you have the NS text view NS text field for equivalent editing ability.

And then from the static text frame of usage, you have the resourced, the nib files for instance, for the views and controls, and the strings file. Excuse me. That is the ultimate way to localize your application and so all those, of course, are available to you for text input to Core Text.

Now I wanted to list here also how you would package this text and the sanctioned way to do that is using the CF string, but Core Text eats CF contributed strings. If you made it to the morning talk on Core Text, it showed how to create your frameset and all of that using your CF attributed strings. But from a Quick Draw standpoint, you've got probably old strings built with Pasquel and C that you need to convert to a CF string and there are APIs available for you to do that.

The first one I list here is just taking straight Unicare, the two byte unsigned quantity for Unicode and pumping it through the call CF string create with characters. You get your CF string from that, but now creating a CF dictionary along with that CF string you could create a CF attributed string and this is very powerful and really exciting to use because now you've got a complete picture of the text and how you want it drawn all in one complete CF package.

And lastly here, I wanted to point out the calls, the CF string create with C string and Pasquel's string and with bytes. The with bytes is the most general translation string call you can call. You can define whether you want byte swapping or the byte order mark looked at, and lots of options to use in that. So you're not limited to UTF 16 with that particular call.

So I wanted to give an example of converting an old Pasquel string to a CF attributed string. It's really not as daunting that you may think. You just need to bear in mind that in the old Pasquel world and in older Mac documents, you need to keep track of the encoding, such as Mac encode, Mac Roman encoding, Mac Japanese, for instance.

Most of the time you already know what the encoding is and there's a few APIs out there that would give you hints, at least, in the case that you don't know what the encoding is. The CF string get system encoding and get application text encoding from an application centered point, they can give you hints and many times it might be wrong, but for the most part it would give you hints as to what encoding your text is originally in.

so as an example, let's say you've got a Pasquel string here, hello world, I put it in the CF string create with Pasquel string conversion call, and since I already know what the encoding is, Mac Roman encoding, I put that in the call here and create my CF string.

Now if I create a dictionary with just one element in it, the CT font, for instance, with the new key, CT font attribute name and combine this dictionary with the CF string I just created, I can create a CF contributed string. It's really that simple, just two quantities. Bam, you got it. Now the other element to Quick Draw that is front and foremost to a lot of people are graph ports. You don't need to use graph ports any more.

In a sense they're deprecated along with Quick Draw. So the ideal way, at least on the Carbon side, to get your graph port is from an HI View event. The K event control event, for instance, would be an event that you would call back on in which to draw items on your frame. So in this case the K event for MCD context ref is gleamed in order to get the CG context from the HI View.

But as was covered in the earlier talk on Core Text coordinate flipping, the coordinate system from HI Views are going to be flipped, unless you set them up normal, as Quartz likes to term it ahead of time. But if it is flipped it's very straightforward to flip it back and draw your text in a right handed coordinate system.

Now in this case, if you really wanted to do the translation correctly, you would flip it and then move it down by the size of your box. But you get the idea that it's very easy to translate your CG context. I wanted to list also a few calls that may not be equivalent, but at least can reflect on to what you do on the Core Text side of things from Quick Draw.

The FM swap font get F num, text font, text size, all those calls are basically setting font attributes on your current graph port, or getting the family ID. The CT font create with Quick Draw instance, which we'll go over a little bit later, can get you a CT font using a font family ID.

Now the draw string draw text, you've got three choices, really three levels on the Core Text side of things to draw your text. You can do it from a frame, which is used in combination with a bounding area in which you want your text to be constrained, or a single line, or even on a run basis.

Most people don't need to work on a run basis, but if you're constrained within your app because Quick Draw also worked on a run basis, but not really tied, you may want to gravitate towards that type of drawing. But it really is not necessary and you can draw entire paragraphs using your CT line draw frame.

The measure justified, string width, text width, all those calls can be gotten from equivalently in the CT line get typographic bounds. And the other measured calls, care to pixel, pixel to care, there are equivalent calls in CT for these too. So you could actually walk your string visually, many of the same things you would do in your Quick Draw app.

I wanted to give an example next of the old way of giving your font reference in Quick Draw. You would get a Pasquel string for instance, say in Helvetica and put that in the get F num in order to get the family ID. Well this is fraught with some inaccuracies because these are in the days when fonts were one font for one face and it was really straight forward to get this family ID.

Things started getting complicated when the fonts became true families, with multiple styles and what not, and you weren't really guaranteed what you were getting and thus we came up with more iteraters and what not to go through these font families. But this was the basic atom of font reference within Quick Draw at that time.

So it's very much preferred to create a font descriptor ref in a CT font using Core Text. And the reason is because it's a complete package and a complete picture into which font face you actually want to use. So I wanted to give an instance of using the CT font create with Quick Draw instance. Here I'm using the Pasquel string again, the Helvetica Pasquel string in this call, and notice there's parameters for the style and size.

I didn't need to put the size defaults to 12 anyway, but you get the idea that the CT font is now tied to a specific instance of your font that you want to use for your text rendering, the size. It gets much better than that, though, which I'll allude to later.

Now I want to give an alternative. This call can actually take a family ID instead of name and get the CT font that way. And lastly you can create a CT font descriptor and use that in the CT font create with font descriptor to get your CT font ref that way, too.

So there's a lot of ways to get your CT font in the Quick Draw world, if you may, but the best way is just to create your CT font descriptor, which we'll go into later, on the best way of containing all the attributes that you want attached to that CT font. In this particular slide, I wanted to give an instance of what you were doing, probably, maybe not, for complex text drawing in Quick Draw.

The main point about drawing in Quick Draw is that it's a run at a time. You can't just define a bunch of runs and then tell something to just draw it. You had to draw a run at a time because every time before a run you had to set the font, the style and size and etcetera. So that's an important point that is advocated into using this CT font descriptor within your lines.

You also needed to use the Script Manager to determine the display order. This isn't really relevant anymore, but Script Manager and Quick Draw worked hand in hand in order to determine run directions and what not. And lastly, you needed to keep track of what's called slot values and save the screen pixel width in order to position these runs correctly, especially for cases of flush and justified text.

So here's a little, it's much, much simpler than what you'd actually have to do in Quick Draw in order to render complex text, but you'd first need to break the line, find a good break point, meaning a space character, the style of line break will find this offset using the starting offset and give you a break code. And then using the family ID you could find the script code and then using the script code, find out what direction this text is supposed to be going.

And now know the text direction you could rearrange all these runs accordingly to get true bidirectional text. Again, I really don't think anybody's doing this anymore because World Script One isn't even supported on the system so you wouldn't be able to get rearranged Arabic in this case. Now before you draw, of course, you've got to set the family ID, the face, and the size and I don't have it here, but you'd also have to set the position, of course, in your current graph port, and then after drawing update your offset and loop.

Now for drawing using Core Text, you have multiple levels in which to think about your text, from a typesetter, frame setter, line or run. Each one of these serves a purpose and you may find different uses for these within your code, but always keep in mind that Core Text works with floating point, so when in doubt use double precision.

All the matrix and everything are floating point. So don't rely on the CG context show text and show text at point because that doesn't do Unicode layout. A lot of people are under the impression that this would do advanced layout. It doesn't. This is very low level drawing call for your text. We don't suggest using this at all for any Unicode text in your system. You may find these in such open source code as Web Kit.

But before they're used, there's a huge amount of analysis going on if you'd take a look in there and that is to determine whether it needs to do complex layout or not. I have a feeling that as Core Text becomes more of a standard, well know to the developers, that eventually that will just switch over to use Core Text directly. Because the reason it really had to go through and use this elaborate scheme was to get around performance problems in ATSUI. That's no longer an issue when you start using Core Text.

So a Quick example of how fast it is to render a line of Unicode text using Core Text. You would create your line using your attributed string that we went over before, set your position within your CG context and draw. It's really that straightforward. There's nothing else you need to do. Do a CF release on that CT line of course, because it's a CF object. But this is great. It's totally thread safe. And you can use this within other threads.

So Quick Draw. It's really been real, it's been fun, but it's a convoluted process to use for any multilingual and multi-style text. I'm sure there is huge infrastructures built around it now and it's served it's purpose in the past, but now those results were probably wrong, because now you're missing some essential elements to your text in today's world because it doesn't use Unicode. It can't handle the advanced font technology coming out now and it doesn't work well with the current graphics system. And it's certainly not 64 bit clean.

So with that, I would like to say goodbye Quick Draw text. We should have a little tombstone here for it or something. But I think that's enough to say that Quick Draw text is very deprecated and we would love to help you move off of Quick Draw text to our modern text system, Core Text.

So the next topic here is ATSUI. Now I don't say this lightly that I like Core Text better than ATSUI. And that says a lot coming from me, because I pulled my hair out developing ATSUI. I really put my heart and soul into it and I wanted to make it the best Unicode layout and rendering machine ever.

And it served it's purpose in the pre Mac OS X days and is going strong still. But there's a better thing out there now, and that's Core Text. And I'm really happy to present the difference now for you. So ATSUI. It's showing it's age. It was actually developed in the Max OS 8 days. It was first presented to outside developers in Mac OS 8.5.

And with that, when Mac OS X came around, everything changed. We had to shoe horn ATSUI into this modern system, which meant getting it to render into your Core Graphics reference. What it was doing before, it was rendering through Quick Draw, actually. That's why it lives in the Quick Draw framework. But now it had to render into Core Graphics.

So we added an attribute, as you probably know, the CG context ref attribute. And you can attach that to your ATSUI text layout object and everything's great, right? Mostly. There's some caveats to that. Measurements sometimes are not optimal or correct, depending on when you've defined that attribute and when you've laid out the text. So there's slight little tweaks in there that really bug people to no end and I totally sympathize with them. But ATSUI's doing the best it can with where it was coming from.

So it's got a lot of baggage to keep everything up in the air and to be backward compatible with all those applications that use ATSUI. In fact there's bugs in ATSUI that can't be changed just like Quick Draw, because it would screw the developers who were already using it. For instance I just came across a bug for getting your glyph curves for vertical text. It's not rotated. But we can't change it at this point, because everyone's relying on that fact. So it's got a lot of baggage and it lives in Quick Draw where it began.

It's time to move off of ATSUI. It really is. So let me list a few reasons why you'd want to move off of ATSUI. It's not integrated well with other frameworks, other modern frameworks, at least, such as Cocoa. And it's really kind of a hack for our Quartz system. Performance is difficult to optimize, as many of you have probably found out.

Whether you should hang on to the ATSUI style or not makes a big difference. Whether you set an attribute to one point or another can actually make a huge different in your performance. It's kind of tricky. It's still, of course, usable, but it's mystifying to a lot of people, including myself. I'm still discovering things that weren't expected that happen to be really surprising a lot of people.

So along with the performance, the internals are then moving away from its usage. It just isn't fast enough. As I mentioned, App Kit has moved totally off of ATSUI, because it wasn't delivering the excellent performance that it's users would expect. So that's one of the main reasons Core Text was developed, to assess that need for the fastest possible Unicode layout and rendering. And it's not available for 64 bit. So if you're expecting to write a 64 bit app, dyou can't do it using ATSUI.

And my last reason, which is the best, is that it's really straightforward to use Core Text instead of ATSUI. Both of them are object based, for instance the ATSUI style object you can basically say yeah, that's a CT font descriptor. It contains all these attributes and which font you want to use and all that stuff. The ATSUI text layout object can be though of as a CT frame.

So it has a lot of similarities that in many cases you could draw complete parallels over, which I'll show in a line break instance here of how closely resembles ATSUI usage. And of course, they both use Unicode for their text, so you don't have to change the underlying layer of your Unicode text input and storage.

So why would you want to stay with ATSUI? There's actually some valid reasons of why you'd want to stay with ATSUI. Core Text doesn't have the text editing ability that ATSUI does. So if you built your edit machinery around, your text editing machinery around ATSUI, it may be best to just stay using ATSUI. ATSUI had some great APIs for doing insertion, deletion and keeping track of all this stuff. And Core Text, as of yet, does not have that.

The other reason would be ATSUI specific attributes. There are a few attributes in ATSUI that aren't accessible from Core Text. But I don't think you'd really be missing much because these attributes are so rarely used we haven't found cases where fonts actually used the attributes that were set.

For instance the just priority overrides. I love this one, because no one ever uses it. It wasn't carried over to Core Text for a reason, and that was no one uses it. There was another attribute like tracking that I haven't seen in a font yet. So a lot of these attributes were shoved into ATSUI before we even had working fonts, because the idea was that if we make it, then the fonts will come. And that just wasn't the case. A lot of these AAT advanced features were born in the Quick Draw GX days, and we all know how that ended.

So the other reason you'd want to stay with Quick Draw, I mean with ATSUI is that your app uses glyph curves. ATSUI has a great way of accessing these glyph curves. And a lot of applications need these glyph curves in order to draw them themselves and do some kind of morphing to them, you know stretch them, grow them in the center, whatever.

One of my first text applications I worked on, Card Ship Deluxe, I don't know if you remember that, but it had this text morphing ability to it where it had to grab the glyph curves in order to do this. Now in many cases, you don't need to draw your own curves to get that effect. You could do your own translations within the CG context. So you should reinvestigate whether you really need to be drawing your curves in order to get these advanced effects.

The last reason I'm listing here, it's really kind of scraping the barrel, and that is you're ATSUI app needs to mimic Quick Draw. This was born out of the need for Quick Draw developers at the time before Mac OS X, to make the switch to use ATSUI so they could render their Unicode text, but they couldn't afford to have their application look any different than it was before.

So all the glyph placements, the flow, everything was as close to the original Quick Draw text rendering as could possibly be and ATSUI still has those special attributes for obtaining that. Obviously you wouldn't want to do that from a Core Text standpoint, so we don't have that ability in Core Text.

So those are the four main reasons why, I could think of, of why you'd want to stay with ATSUI in your coding and development. Now to give you some basis on some of the similarities of ATSUI and Core Text, it's a lot closer than Quick Draw, of course, because ATSUI is at least Unicode based and it uses objects.

So the ATSUI draw text, it's main drawing routine can be gleamed from the Core Text side from three different draw calls, the frame, the line and the run, which I'll touch on to later in this talk. Getting font features and variations, no sweat. You can do that in Core Text also. And bounds for your typographic and your image bounds can also be gotten from Core Text, too, just like you did in ATSUI.

Now moving to the end of this list here is the ATSUI break line. Very important call that you really need to call for doing your paragraph breaks. There's also a batch break line, too. But that was put in by just lots of pressure to get things speeded up.

With the CT line suggest line break, it actually comes out faster in that the call tells you where a good place to break is and then you create the line based on this information. In our speed test, sometimes it comes out twice as fast as ATSUI. And I invite you to try your own speed test, because it's so easy to look at.

So next I want to talk about those ATSUI font IDs that everyone's carrying around. You can easily convert it to a CT font ref by using the call CT font create with platform font. Here I'm first converting my ATSUI font ID to an ATS font using the call FM get ATS font ref and font.

And along with this parameter, I've also got the size, like in the earlier examples, but I've got a transform that I could optionally set, and a font descriptor. So I could add this slew of attributes to connect now to my CT font along with my original font ID.

Now comes the really fun part. When you're breaking lines in a paragraph of text in ATSUI, you do three basic things. You need to find the break point, you need to measure, and then you draw. And then all that other stuff is just keeping track of where you're going to be drawing and where your break points were.

A lot of you recognize this stuff, you've done it a million times, I'm sure. Bear in mind also, that all of the quantities coming out of ATSUI are fixed quantities, not floating point. So you need to convert those. Also there is coordinate flipping to do. ATSUI is a little schizophrenic on it's coordinate frame. Any information coming from the fonts is still in that flipped coordinate system, but then when it draws it things it's in a normal coordinate system. So you need to keep track of this stuff pretty closely when you're drawing using ATSUI.

Drawing and breaking lines using Core Text, is very similar, albeit it a little bit simpler. Here you can find your line break using the CT type serve suggest line break and then create a line based on that break information. Now you would think oh, the lines, all separate from the paragraph. No. It's all connected. And you get can your line entity in which now to operate on and one of the operations, of course, is getting the typographic bounds so you know where to draw this line.

Notice the difference here that we're setting the drawing position using the CT context set text position instead of right to the calls. That's an important distinction between Core Text and ATSUI that your in control of the CG context when you use Core Text. With ATSUI it's w little hit or miss with what's being updated in your Core Text and what's not.

So it's really an object of a lot of headaches on trying to figure out what's changed in your Core Text. So what many people resort to is actually saving their CG context ref and then restoring it after they've done the draw. Of course, doing this takes up valuable cycles and its not a good thing, in the end, to do. But that's what a lot of people had to resort to to get around that ambiguity of what is actually changing in your CG context. With Core Text you're in control and it's very up front of what needs to be done.

And like in the previous example here, I'm updating the range location and the white position and then I go across with my loops. Now this example, you don't even need to do a break line, because now we've moved up a layer in the Core Text by using the CT frame setter. If you know the bounds that your paragraph is in, just use CT frame setter do the drawing for you. It's really straightforward and easy to do. Why do elaborate break lines when you already know exactly what the bounds is going to be.

So with that, I'd like to move on to my last topic, which is interacting with the user interface, in particular the fonts window, or fonts panel, as a lot of people refer to it. And what I have to show in the next few slides is that it's really a snap using Core Text for getting any changes the user might have set within the typography panel that pops up in the fonts panel or the fonts panel itself.

So in this slide, I'm showing an easy example, really a small snippet of what you need to do using ATSUI to gather the changes made by the user in the font panel. Here I'm getting the features, but you would also need to get DK event param ATSUI font ID and the font size and variations and ATSUI attributes. And you would need to set all of these individually.

There's quite a lengthy process to go through. And in some cases, you may even miss out on a few unless you did it exactly right. In this example I'm getting the even parameter K event param dictionary, and using that dictionary, I get the font panel feature types key. And with any features types you've got to get the selectors.

And now with the feature types and selectors that you've gotten from these dictionaries, you've finally set it within your running style and your app with the ATSUI set font features. So that's the features, now you'll need to do that with the variations and all the attributes and the font ID, of course, to make sure that you're up to date with any user changes in the font panel.

Now what's great about Core Text is there is a single event parameter, the K event param CT font descriptor. That contains everything. And you do a simple merge onto your existing runtime font descriptor that you're holding onto to get up to date with what the user has set.

This was also touched on in the hands on session earlier in the day, so I highly encourage you to take a look at that application. It's got a lot of aspects to it. Even drawing along a curve and rotating a CG context to do some pretty sophisticated text treatments.

So using the CT font copy font descriptor, I can get my current descriptor ref from my CT font, which can always be gleamed from that, and using the get even parameter for the new even param CT font descriptor, I can get the changed attributes from the font panel. And then the sanctioned way of merging it then with your existing descriptor is to copy it in using the CT font descriptor copy attributes.

That's how you get the attributes out of the new descriptor. And using that, you sue the CT font descriptor create copy with attributes, which actually merges those attributes together. And finally you would create your new CT font descriptor using the CT font create with font descriptor and you're done. This may look like a lot, but compared to what was needed for ATSUI, this is nothing. This is a blip. And you're guaranteed that everything is correct.

So Core Text, it's really a meaner, leaner text machine. And I think you'll whole heartedly agree with me once you stat digging into it a little bit more. I'm really excited about it's entry into the public domain now. We can finally get some real external interactions now on what would best be the direction of its future. And we've already gotten a lot of feedback from you and we welcome even more.

It is very similar to ATSUI, you'll find, and in that way I'll make the transition a lot cleaner and easier. Core Text is, by far, faster than ATSUI. It is advocated for use within our system to speed up our overall text layout and rendering. So if you want the fastest possible text rendering and layout, definitely consider Core Text. And ATSUI is really an old interface, as I mentioned.

It was shoe horned into Mac OS X because really there wasn't anything else out there. And when people finally started to getting to know Cocoa, of course, that was a viable alternative. But on the Carbon side, you're kind of left with this antiquated API set and Core Text is a great alternative and progression on the text layout front for Carbon developers.

Core Text was defined for Mac OS X, if I didn't mention that already. And it actually used a lot of ATSUI's best parts. Some of it's AAT table processing stuff, a lot of lessons were learned from our development on ATSUI to make this the fastest and most stable text rendering and layout engine out there in the world, I think.

So I want to summarize this whole talk by saying Unicode, first and foremost, is the standard for text. So really, use it or lose out. There's a huge amount of capabilities available for Unicode text rendering and layout. And I think you will greatly appreciate using Unicode as the main format for using, for storing and editing your text. Quick Draw API is dead. Rest in peace. It is deprecated. It's not Unicode based and not suggested. So please don't use it. It really doesn't do you or your company any good to continue using Quick Draw.

ATSUI is still viable in some cases, but it definitely has performance problems, as many of you have knocked down my door pointing out. There's not much more we can do about it in that it's stuck with the current functionality it has and it's reached that asymptotic limit of how fast it can actually be.

There are certain things about it that are almost impossible to fix. It's so rooted in it's old structures that at some points we just threw up our hands and said well, let's put our energy into Core Text. So really ATSUI has given all it can. And Core Text is really what Apple is banking on moving forward.

So all of our future development for text at this level is build on Core Text. ATSUI is not getting any more APIs and some of its APIs are already deprecated. So that's really kind of a show of the times to come for ATSUI. We're not going to ever pull it out from everybody, but just be warned that the development for ATSUI is limited, at this point. And we're putting a lot of effort in to making Core Text our best text rendering layout engine out there.

And most of all, switching to Core Text is very straightforward. And I think you'll find that it's incredibly intuitive to use and it's pretty fun. So let us help you. We are developing this stuff to make your applications as good as possible and as high performing as possible. And we really are trying to keep your best interests in mind, so we appreciate your feedback, too. So I think you'll really be pleasantly surprised by how insanely great Core Text is.

So for more information, the usual suspects, Derrick Horn, the Application Frameworks Evangelist and Allan Shaffer for our graphics. And documentation, sample code, all that stuff from the usual place. There is also the hands on session that you should really check out from earlier today in the Core Text talk. In the lab, we can work with you, if you have an old, crusty Quick Draw app, we'll certainly sit down with you and see what we can do about making it as painless as possible of souping it up and using Core Text.