Mac OS. Hmm, sure at that point you're already wondering how this French guy with such a thick accent is going to keep me awake talking about text. So maybe that will change your mind. Text on Mac OS. Actually, I prefer this one. Real text on Mac OS. So welcome to session 155, Real Text on Mac OS.

We'll be talking today about the technologies that's going to enable you to handle Unicode text on Mac OS X, Mac OS 9, next version of 9, and of course, CarbonLib. We'll be talking, of course, about advanced typography on the new system. We'll be talking, too, about MLT, the multilingual text engine.

All right. Whatever platform you're developing for, Cocoa, Carbon, or Classic, when I say actually Carbon, I talk about CarbonLib and Mac OS Xenon. Or Java, you need to handle text, or most applications do. There are, in my mind, two ways to handle this. There is the hard way, and there is the easy way. The hard way, your application needs very fine control and very fine tuning of the style, where the glyphs are going to be positioned on the screen. and this article the steps But you have to follow in order to enter text. You have to do text input.

It could be by different settings, but character set conversion if you want to enter I/O. So from different encodings, files that are coming from the net, UTF-8, files that are coming from Windows, text manipulation and text layout, reordering of the runs if you're doing multi-script text, and of course, the rendering. And there is the easy way. The easy way would be to use one or several text packages. And the text packages would actually use one of the several layers we have there.

Let's see. The text solution that we have right now for Mac OS X and classic applications. So once again, the different technologies I'm going to be talking about are available on 9, CarbonLib, and OS X, of course. Here again, I will divide that in two settings. Will be what I call the pre-Unicode.

And I'm sure you have been using one of these technologies, text input, where you could do it with like, you know, the event record where you get a key down. Or you could be using TSM, Text Services Manager, if you need to enter two byte scripts. The character set conversion has been used by TC, the text encoding converter. I'm sure you have heard about that. Text manipulation, the script manager, the text layout, and the rendering, as you all know, Quick Draw text and Quick Draw.

Since 8.5, we have been introducing technologies so developers can enter UniCode easily. These technologies are of course available on Mac OS X. Text input. If you want to do Unicode input, there is only one way, and this is to install the TSM handlers. Character set conversion, of course, you still have to use TSC. Text manipulation, in order to do Unicode line break, sorting, for instance, you use the Unicode utilities. The text layout, you'll be using, at three, Apple-type services for Unicode imaging, which is the only way to do Unicode layout correctly.

The rendering, quick draw, and of course, moving towards new technologies, Quartz, if you're working on 10. Before we go into details and we talk about each of these technologies, I'd like just to, like, you know, actually I forgot about this one, sorry. For the easy way, the text packages, you'll be using TextEdit.

I'm sure you've heard about this technology. And, of course, for UniCode, MLT, the multilingual text engine introduced on Mac OS 9, available on CarbonLib and on 10. So before we talk about these technologies, I'd like just to make a quick reminder why UniCode is important. UniCode is an industry and Internet standard. Even Windows uses it. And no, UniCode is not a monopoly.

It's the only way to handle new languages. There is no more room in Word Script to handle more languages. Unicode is the solution. If you want to handle the new extensions for the big five, for instance, the Hong Kong extension, handle the extended character sets for Roman, or access the new gliss that have been defined in the GSX2013 standard, the only way to do that is to use and to encode your documents in UniCode.

I'll give you a quick example. Right now, for the characters that just appeared, these characters are part of extended Roman character set. Right now, if you use quick draw text, the only way to render these characters is to use five different encodings. That means if your applications want to run in Hungary, you need to find a different font than the one that is shipping on the US system. That means to support these characters, you need five different fonts.

With UniCode, only one font-- and I'll show you that in the demo-- is sufficient. And a font like Geneva, for instance, is already set up for that. Before we go to the demo, I'd like to introduce Deborah Goldsmith, who will be talking about the different block technologies. Deborah is a manager for the International Toolbox, which owns the ZWEE technology. Thanks. Actually.

So Xavier talked a little bit about the system components that an application can use to support UniCode, and I'd like to talk about those in a little bit more detail. To put them in context, here's a diagram of the flow of data in a Unicode application. First of all, you have information coming into the program, either coming from the network or disk, possibly the internet.

If it's in a legacy encoding, you need to use TEC to convert it into UniCode. If it's coming from the keyboard or some other input device, use TSM, the text services manager, to process the input and make it available to the application. After your application has done its processing, use ATSUI, Apple type services for UniCode imaging, to lay out and prepare the text for display. And then finally, you can use QuickDraw or Quartz on Mac OS X to display the characters. Now I'm going to talk about each of the technologies in a little bit more detail.

First of all, the text services manager, which has been in Mac OS for quite a while, since 7.1 at least, I think, It was there first for support evasion languages, but over time it's been taking on more and more functions. Right now, it is the only way to receive Unicode input in your application.

So it's necessary if you want to get Unicode directly from input sources. As I already mentioned, it supports input evasion languages that require input methods, but it also supports other kinds of text services. Examples include spelling checkers, hyphenation, and even speech recognition. And starting in Mac OS 8.5, TSM added support for one-byte languages as well as the double-byte Asian scripts.

New with Mac OS X and CarbonLib, TSM now supports the Carbon Event Model. So you can continue to receive input from TSM using Apple events, as you have in the past, or you can now use the Carbon Event Model instead. And TSM also takes care of matching up Unicode and non-Unicode applications with Unicode and non-Unicode input sources. So your application doesn't have to worry about whether a particular keyboard or input method produces Unicode or legacy character set output. TSM will take care of converting it for you into the form you need.

The UniCode utilities were new in Mac OS 8.6 and were extended in Mac OS 9. They're equivalent to the international text utilities and the script manager, which have been in the Mac OS for a long time, but they're the equivalent versions for UniCode text. They support operations like collation, namely comparison and ordering or sorting of text in human languages. They support text breaking, finding boundaries between text units like words, lines, or even clusters of characters.

In addition, they provide access to information about characters, such as whether they're left to right or right to left, or upper or lower case. And these come from the UniCode 3.0 character properties database. And finally, unlike the script manager in international utilities, which use the model of a script code and a region code, which are unique to the Macintosh, the UniCode utilities use a new locale model, which is very similar to the way that Java and Unix systems handle international processing.

ATSUI, or Apple Type Services for Unicode Imaging, is our solution for drawing Unicode text. It was introduced in Mac OS 8.5, and we've been extending it and improving it with each new release, and we continue to do that. ATSUI is the only solution on the Mac OS for direct imaging of Unicode that is handling all of the Unicode standard, not just small pieces of it.

It provides a larger character and language repertoire, covering new languages that you can't do any other way, plus parts of existing languages that are hard to get to using QuickDraw. So the example you see on the screen has Thai, Vietnamese, Greek, and a few other characters I'll describe in a moment. The first part of the example is all from the Lucida font that's part of Mac OS X. That's all in one font, handling Thai, Vietnamese, and Greek, as well as Roman.

The characters at the end are characters that are in the Times font, which has been shipping on the Mac OS for many years, but those characters can't be gotten to through QuickDraw. They're characters that are in Unicode and in the Windows character set, but not in the Mac character set.

So even though they're in the font, there's no way to get to them. Many times I get emails from people using Windows systems, and they have characters like this in them, and it's not possible to display them. Except now with UniCode and ATSUI. ATSUI also supports the full UniCode bidirectional model, which is very complicated, supporting languages like Hebrew and Arabic. And for languages like Arabic and Indic languages like Devanagari, ATSUI supports complex rendering of text.

ATSUI has other features besides access to more languages. For example, for Asian text, in QuickDraw, double byte text is required to have the same width for every character. So every kanji or kana in Japanese, for example, has to be the exact same width. With ATSUI, you can have proportional double byte text.

Different glyphs can be different widths. In addition, ATSUI supports something we've had many requests for from our Asian developers, namely vertical text. The same features of ATSI which support complex scripts like Arabic or Thai or Devanagari also support advanced typography for Roman languages, so you can get advanced typographic effects.

So we haven't been sitting still with ATSUI. We've been adding new features. And new for Mac OS X are APIs for accessing the outlines of glyphs and glyph metrics. And this is specifically meant for applications that have used ATM to do this in the past, since ATM is not available on Mac OS X.

In the future, we plan to do much more to ATSUI. We're working on it very actively. The first thing we're going to do is lessen its reliance on Apple layout tables. So right now, to do the advanced typographic effects or certain kinds of language support, you have to have Apple advanced typography tables in your font. We're going to continue to support those because we think they handle those functions very well, but we want to make ATSUI work better with more different kinds of fonts.

So the first thing we're going to do is make it able to do advanced layout and language support using fonts that have no layout tables at all, because that's what most of the fonts out there have, no layout tables at all. In addition, there are more and more open type fonts coming onto the market, and we want to support those as well and take advantage of the layout tables in those fonts. So that's something we're going to be working on for future versions of ATSUI also.

In addition, there are many developers, such as those working on high-end page layout applications, who need very fine control over the layout process and the positioning of the glyphs in their applications. And we are going to be adding a low-level layout API to ATSUI, which will give those developers the control they need. And those are all coming in future releases, and we're working on them right now. So now I'm going to turn the stage back over to Xavier so he can talk about the multilingual text engine. Thank you. and the University of San Francisco. There you are. Thanks, Deborah.

The multilingual text engine. So as Deborah described, this is how your Unicode application would look right now if you were to use these technologies. What MLTE is going to do for you is going to try to shield you from the complexity of dealing with all these technologies. It's a Unicode text engine, and let's see what is exactly MLTE. MLTE is a replacement for text edit. And that's important to say that it's a replacement for text edit.

I said it twice. A complete UniCode text package. And when I say complete UniCode text package, it's because we do UniCode input, UniCode layout, and UniCode display. We don't lose information during the process of rendering the text from the input to the rendering. It's easy to adopt. And we have sample code, actually, for proving that. And I encourage you, we have some documentation slides to show, to see the MetroX project that we have.

It's one set of APIs and it's supported on three different environments. On Mac OS X, of course, 9, and CarbonLibre. 10, 9, and CarbonLib. So that means you can go back to and start checking out the demo that we have. You can start coding on 9 just to find out if actually this is correct, this is a good technology for your application. And when you use the APIs, the same APIs are going to work on CarbonLib and then on 10 transparently.

Oops, getting confused. It's written in English. For the demo, I'd like to invite on stage John Harvey. John Harvey is the tech lead for MLTE. We've been working on MLTE for a couple of years now. And we'll show you exactly what MLTE can do for you from a graphical point of view and from a UniCode point of view.

All right, so this is DP4 with a couple of enhancements. This application is Champollion. You'll find it in the system demo folder. It's using right now Quick Draw Rendering and NetSuite for the UniCode layout. Here, when you create a new document, what's happening is that you get this default window. At that point, MLTE created, with one call, the handlers for the drag and drop, the handlers for TSM, so your application can handle two byte scripts.

So now you don't have to spend time installing the TSM handlers. We get them by default. The scroll bars, we handle active scrolling as well. So this is important to notice. This is one call, TXN new object. And it's going to do all these things for you. All right, so I have my little cheat sheet here.

A big difference with what you're used to, for instance, if you use simple text or the quick draw text, here the font menu is organized by font family. And here, for instance, an instance like Courier. Courier has bold, bold italic, which are different representation of this font. So here the font menu is created automatically by MLTE. It's, once again, one API. You pass a menu handle, and we're going to build the hierarchical font menu for you.

Something new if you use it, too, is that phones now have way more information. So not only the Unicode information, but they have, as well, advanced typographic features. And you have two set of features. You have the first one that are not presented here, and you have phone variations.

So here, a phone, like Skia, for instance, has different representation for the glyphs. These representations are formulated by the phone designer. The phone designer decided, well, I'm going to do an instance of a Skia phone that's going to be represented light, or extended, or bold, or super bold. So here, once again, at that point, your application calls one API, and MLTE, the text engine, is going to handle for you what's the current selection, change the text, do the reflow if reflow is needed, redo the break line.

Let's see now why Unicode is important. And by default, when you're going to use MLTE, you'll get all that support and all the Unicode support. So here we have a Vietnamese file. This Vietnamese file is encoded in Unicode. In this case, it accesses a lot of the characters that are in the extended Roman character set. This file cannot be rendered with quick draw text for the very simple reason that most of these characters cannot be encoded if you use a Mac OS Roman character set.

So for instance, on the right of the screen, we have simple text. Here we're going to try to drag and drop Part of the text to simple text. And what can we see at that point? So first, what happened in your application? You got a click. You send the click event to TXN click. At that point, MLT is going to handle the rest.

We're going to find out it's a drag and drop. We're going to export different flavors to the drag manager, so the drag manager and all the applications can understand it. And in this case, what we did is that we exported from UniCode and that style to something that simple text can understand, which is Mac OS Roman text plus style information.

And here we can see that during the translation, we used TEC, of course. As good TEC is, it cannot render certain characters. So you can see, for instance, on the second line, the NA, TEC has been sufficiently clever to find out that, in fact, it could decompose the UniCode character into Mac OS Roman characters. But then, of course, after the M, you can see that this glyph doesn't exist and cannot be rendered with Quick Draw text, so we place it here with a question mark.

So what's the font here that we're using? This is Lucida Grande font that is in Mac OS X. And this font has all the extended character sets for Raman plus many other glyphs. And we can talk about that during the Q&A if you want after. So we access the Roman extended character set, which is good.

But one thing important for customers, too, in the Japan market is all these extensions to, for instance, Big Five and the new GX213 I've been talking about. Using Unicode and using Hatsui, and of course, when you use MLTE, it's transparent for you, gives you access to these new glyphs.

And here, for instance, the three first, the first three lines, can be rendered with Osaka. The Osaka font has these glyphs. But we can see that the glyphs after cannot be rendered. They're just not present in the Osaka font. And here, the font is Iragino, which is a new font introduced on Mac OS X. And this is the only way you can access these fonts. There is no other way to do that.

So I didn't talk about the last two lines actually. The last two lines are variants of the glyphs represented in the GIS X2113 standard. The way to access VZLift actually is just by phone variations. And I'll show you why variations are so important and features are so important when you display and when you layout text.

So when you use MLTE, you're going to access all the power of Hatsui and all the power of using Unicode imaging. But a nice thing, too, in using these technologies are the advanced typographic features. And it's just the way the text is rendered. Right now, if you go in simple text, you take a font like Chainsree, change the size to make it a little bit bigger, and you type some text, this is how it's going to look.

Okay, so this is the default behavior, and you type a R, this is the default R. Everybody's gonna get the same glyph. If you copy this text and now we put it in Champollion, Then you get a nice long swash from the R to the A. You get like, you know, the ligature goes back to the A, the L as the end line swash.

And this is the default that you get, but then because we do like, you know, the layout, and that's how it processes the text. You get this behavior, and I think the text is rendered pretty nicely. So we can change the size, make it bigger, smaller, of course. You can go ahead. I mean, that's nice.

So here on the palette on the right, you get the usual styles. So you can select text, type some text. And as I said, now when you're going to be using MLTE, and because we're using , we can access all these advanced typographic features, things that before you couldn't access just because we didn't have the APIs and the quick draw text is too limited to do so.

So here we type some text. You can see that during the time that John is typing, the text is changing. Because for instance, here the S is going to change. The ligature on the E is going to move. , which means the eggs in French. You see the F changing.

If you know a little bit of French, you know that "euf" is not written like that. In fact, there is a diphthong between the "o" and the "e." So how are you going to do that? So as I said, each font that Apple has been shipping in the last, I don't know, many years, has a setting of features. So here what's happening is that Champollion gets the current selection from MLTE and asks the font, "Give me the list of all the features that you have." And here we are. So we have a bunch of typographic features, letter case, diacritics, vertical position, fraction.

All these things are stored in the font. So here, for instance, we can turn on the diphthongs and hop, the layout changes. The text is the same. We didn't change what's stored as text. It's just the way the layout is processed. Now we have a diphthong setup. So at Sue, it's really clever to know that the O and the E has to be combined. So we have, of course, things that are like swashes, rarely get used. And you can see the nice compartment, the S going to the E.

If you use MLTE in your application now, you're going to be able to render text like never you've been able to do before. And it's like, you know, you have all the power of UniCode. You're going to be able to access the two-by script without focusing on how difficult it is to render this. And you're going to be accessing all these features. So another nice feature that we have... A phone like Skia, for instance, has been shipping for several years now. It has variations in size. So if we type some text, And we bring back the typographic features.

Champollion is going to be asking to the font, to the Skia font, give me all the variations that are stored in the font. And here at that point, if we click on Variations, we have features as well. So here, just a click on the letter case, we change everything to caps. And what is important here is that the text didn't change. It's just the rendering, OK? If we select this text and put it in simple text, for instance, you'll still have the original text in small caps.

and the variations. So here, Ski has two types of variations, weight and width. And you can see that, you know, just in real time, you can change the way the text is going to flow. You can change the weight, and you can change the width. So it's kind of important for doing layout documents, formatting. It's very nice if your kid wants to create some flyers, things for his school. You can do a bunch of things there.

So, rarely get yours. Play with it, you know. It's in system demo, Champollion. You can play, you can try with the fonts. There are a bunch of fonts that are shipping with Mac OS X, DP4. And play with it. You'll see you have different compartments. I mean, I think it's going to give you an idea of what the technology is about and how you can implement that in your application.

All right, so MLTE gives you access to UniCode, gives you access to advanced typographic features. But as I said, too, it's a replacement for TextEdit. And people have been asking, of course, for many features to add to TextEdit. In this case, most of these things are in Champollion.

So one important thing is embedded objects. MLTE supports embedded objects. And it's transparent. And if you have been creating simple text files, read me files, and you wanted to put a picture, because you know how annoying it is to create the resource-picked 10,000 and put the embedded character CA in the data fork or the text. And then, of course, if you want to ship this file to Japan, you have to change it, because what's happening is that the CA character is the first byte of the two-byte character.

So you have to change everything again. Here, with one format, when you're going to save MLTE, you get pictures, sounds, movies, text, UniCode text, the features, the ligatures, all the phone variations. And here, we just have a movie, and we can play it. You can ship back to your customers.

So with the new releases, we're adding two types for saving these movies, which I think you're going to be interested in. Because if the movie is 50 megabytes, well, if you flatten the movie to the disk when you save your file, you're going to get a file of 50 megs.

So a new way to do that is to just save as a reference. And that's nice, because you're going to be creating your document. You could ship it to your customers. And inside, you could put a movie that is, in fact, somewhere on your network. So it could be just going on the internet and loading the file and streaming it.

So we can see, you can save that in your document. You can type text, of course. Here, if we open a picture-- We get a big picture. Let's try to get just a piece of it. So we're going to copy that. So here, the application is handling it.

You paste it in the document. At that point, once again, one call. Txn paste. Txn paste is going to check what's in the current scrap board. If it's a picture, we're going to handle it for you. If it's a movie, we'll paste it. If it's text, we've styled resource, like the way simple text does things, we're going to paste this in the document. It's one call for you.

And here, at that point, drag and drop, same thing. You get a click in your application. You pass the click to the Txn object. And we're going to handle if you are scrolling. If a click is in the scroll bar, we're going to handle if it's the beginning of a drag and drop. So I think it's pretty powerful.

Before we go to the next, in my first slide, or maybe the second slide, I was saying that, you know, our technologies on 10 are moving forward, and now we're trying to implement and using, of course, like, you know, all the power of Mac OS X. And one of the very nice features of Mac OS X, of course, is quartz rendering.

So what I'm going to show is just something we're working on, okay? It's not finished, but here, we're going to be using MLTE, and when we release this, we'll be using, by default, quartz. And your application... We'll see nothing. It's just like setting a tag. And you'll be switching from Quick Draw to cross-rendering. So here we have a document with a special version of Champollion.

And here we can see we can change-- This is only like, you know, quartz rendering. So like, what's happening at that point is like, you know, we're triggering a CG context. And here, we're just changing the way the shadow is going to look. So we can change the radiance, like, you know, for a shadow. We can change the k, which is like the coefficient for the transparency of the shadow. So here, that's cool. We cannot see it. So let's try to change the height. So here, we change the height. You can see the shadow getting away.

At that point, setting these kind of features is the same as setting a variation. It's just one set. It's like another style attribute we're working on. You can change the angle. So look at that. You have the angle. Can we change the coefficient for the radiation so it's darker? And here we can move the shadow around the text.

We can put it like, you know, far away. And here, of course, if you type text, you can just type, and that's it. We're reducing quarts at that point. You'll get all the nice shadow and the nice effects behind that. So this is coming soon. That's fine. Thank you.

Let me go back to my slides now. So once again, check it out. The version that is in DP4, system, demos, the application is called Champollion. I think the movie support is not enabled in this specific release, but it's just coming soon. You can play with the fonts, check out Skia, Chains 3 is there, Earthflare Text is there. You have a bunch of features. You can play with that.

What can MLTE do for you? So MLTE is going to be handling the Unicode input, the editing and the display. as a complete package. So for instance, if you want to do like two byte input, you're not going to have to install the TSM enders. Once again, this is created automatically when you create a new TXN object, an MLT object.

It addresses many text edit limitations, and I have a slide on the features to show you a set of features that we support. It handles the low level managers transparently. So once again, same thing. When you create a TXNU object, we're going to install the drag handlers. We're going to install the scrollers. If you want a horizontal scroll bar, it's just a flag that you pass to the object. You want a vertical scroll bar, it's another flag.

Oh, this thing is going very fast for me. Which makes adoption very easy. And we have sample code once again to show you that. It provides easy access to its three advanced typographic features. Setting at three typographic features with MLTE, it's just a matter of setting a style attribute. It's like setting bold, it's like setting italic.

All right, let's see what other features. Last year when I did, actually, I talked to a couple of developers. And every time you ask them, what is the feature that you really need in a text engine? If you have to change something-- yes, new 32K limit. I think this is on the timer.

Sorry about that. So if you ask to a developer, he will say that no 32K limit. And MLTE, of course, handles more than 32K text. So you don't have to worry about that. The size limitation is only limited to the memory of your application. So this is great.

Tabulation support. You can now set a tab setting per document. So you know, not like on TextEdit, when you press tab, wow, when you press tab, we're going to have a real tabulation. You're not going to have a space. I'm going to have to go fast. Embedded objects. We support pictures, sounds, and movies.

And once again, the way to set that is just a matter of one API, a handle on the data, wow, a handle on the data, and that's it, you're set. Multiple undoes. We support 32 levels of undoes and redos. Once again, just a matter of simple APIs, TXN undo, TXN redo. We support setting for full justification support.

It's one setting per document. Whoa, it's getting pretty bad. More features if I have time. Gritting/scrolling, as I showed you in the demo. The printing and the keyboard support is done for you. We have APIs to handle that. And if you're moving to Carbon and to 10, for instance, you know that you have to rewrite the printing. And here, if you use MLTE, that will be handled transparently. The I/O.

We introduced a new file format, TXTN, which is the file format that's going to be saved to the disk and that's going to support the embedded objects that you have in your document, the Unicode text, and all of the at-series style attributes. So the features, the variations, and all these things.

But you can still save, of course, if you desire, if you want to do so, as plain Unicode file, and we'll do it automatically for you. TXTN save, you pass an FSPEC and a flag with a type that you want to save to. And we support, of course, the simple text format. So when you use MLTE, you can still export data. So simple text, Apple works, Microsoft Word can understand.

There are two ways to use MLTE. And the first one is for text editing. You'll be using it for labels, small text edit fields, or small editors. And the second way-- and we've been adding that because last year we talked to developers and there is one thing they wanted is static display of UniCode text. They want one API where they're going to be able to pass a UniCode string and maybe some parameters, a rect, and that's it, and it's going to be displayed. And this is the API to use in this case, and I'll talk about that in my next slide.

We have one API now. It takes two flavors. If you're working on Carbon IP10, you can pass a CFString, or if you're working on 9, you can still pass a UniCode pointer and a length pair. And it takes many options. By default, you just need to pass the text and the rectangle, but if you want, you can pass many more, and I'll show you that in the next slide.

The text editing. It's ideal for small text areas and text fields. It does a lot of things for you with very few calls. It supports all that three styles, tags. And this is important if you see the-- oh my god. And this is important because it gives you access to a range of new style and features that you couldn't access before. So MLTE with one simple API is going to give you access to all these things. It's easy to set and retrieve line, words, characters from the document. Once again, now you can call an API and get the fifth word on the second line. Just that.

It takes care of the inline text input, the layout, and the rendering. Once again, when you initialize the text engine, we're going to install a bunch of handlers for you, and we're going to try to make your life really easy so you can focus on what your application is supposed to do and not the way you should handle text. MLTE is going to handle that for you.

The text editing before MLT, just as a quick example. If you wanted to handle two byte scripts, before you had to install-- oh my god-- you had to install the TSM handlers. Then if you wanted to support drag and drop, you have to install the drag handlers. If you wanted to create scroll bars, you had to install the scroll bars yourself. Manage your internal scrap. And of course, manage yourself the I/O.

This is something like 212 lines of code, and we have a sample code to show you that. And this handles only basic scrolling, basic internal script management, and very limited save and open. With MLTE, now, six lines of code. And I swear, you have to check it out. It's very easy.

You can compare the two files and find out that one code is going to do so much compared with what you had to do before we've texted it. One code with the XNU object is going to hand style all the drag handlers. All right. All the drag handlers and all the things to enter the Unicode input.

To manage the scrap, we have two APIs. The XN convert from public scrap, and we're going to take whatever is on the public scrap, convert it to something that your application and MLTE can understand, and convert to public scrap. That's going to take whatever is on internal scrap board of MLTE to the public scrap. And this is very cool.

The XN save and open, same thing. You pass an FSPEC, a file ref, and a file type. So we're going to find out. And we're going to be able to open UTXT files, simple text files, plain Unicode files, or TXTN files. And at that point, it's just a matter of calling one API.

The static text display. So people have been asking for that. TXN Draw UniCode TextBox is the solution if you want to display mono-styled Unicode text. By default, the only parameters you have to pass are the text, a length, or a CFString, depending on what you do. Ooh, this is bad.

So the text, a rectangle to do the word wrap, and if you want, you can pass a bunch of flags in the option structure, which are-- we're going to handle vertical text, rotation, flushness, if you want to justify the text. And if you'd like, you can pass your own ATSUI style. You don't have to. If you don't want, we'll take whatever is in the current graph port, convert the font, the font size, and the style attributes to something that ATSUI can understand.

OK, my conclusion slide-- very difficult. Think different. And Unicode is more and more important. And I think we have the right technologies now for you to use and to implement easily in your application. If you have very specific needs and you need fine control of where the glitz should be displayed, use Hatsui. Hatsui is the solution. It's the only way to display Unicode text correctly.

If you want something a little bit easier, actually I should say way easier, MLTE is the solution. MLTE is like, the text package is going to do so much for you, it's going to shield you from having to deal with the complexity of a toolbox for the scrolling, with the complexity of TSM for ending two byte scripts and Unicode input.

Once again, think UniCode. This is the only way where things are going. It's not on your platform. It's Windows. It's the internet standard now. And your application at one point is going to have to deal with UniCode. So think about our technologies. CarbonLib 9 and 10, the same set of APIs is going to be working.

Think MLTE. MLTE is great. We have sample code. I'll show you that in the documentation. Switching from text-edit implementation to MLTE is going to reduce the number of lines in your code. MLTE is going to do many things that you had to handle by yourself before. So it's a nice way to transition to go to CarbonLib and move forward to 10.

Before we go to the Q&A, I'd like to show you just where you can find more information. On the developer.apple.com, in the text services, we have a list of the current technologies. So you'll find info on specific topics like TSM, if you'd like, , MLT, TSC, the text and coding converter.

There is an MLT SDK available. I don't know if it's already on the net, if it's on Apple website. I saw it last week. We had a kitchen on Sunday, and it's great. There are, like, you know, Carbon examples. There are examples of, like, how to use MLT, how to create the font menu, how to use TXNU object, how to handle the events, even if you're using Carbon events. It's very nice. It's well documented.

The roadmap. So yesterday you hope you did go to the Carbon event model. If you didn't, there is still, like, you know, I think some refresh. Some people are going to have some slides after that. Mac OS X font management. This is the right place to find out about how the Mac OS X font management is going to be going. They'll be talking about the font objects APIs, how to access probably, like, you know, the font tables and all these things. It's pretty nice.

Quartz. Quartz will be exposing some of the APIs that now you can use on 10. Quartz is the way to go. It's a very nice rendering engine. Our technologies will be using it. If you need more info, please go there. Advanced printing. Once again, if you move towards 10, you know that the printer architecture is changing.

Of course, if you use MLTE, that will be transparent for you. But if you need to do your own printing, please go there. They'll have a lot of information. Important. Session 912. It's the feedback forum for text and internet. We'll have a bunch of engineers there. Come by.

We can talk, you know, about, like, if you have specific problems, implementation requests. It's always good to have feedback on the technologies we're working on. Talking about feedback, we'll have, I think, some balloons in the hall for lunch, for international lunch. We'll have, like, three different tables. I think one for font, one for text, and one for H3.

Please come by if you have, like, you know, once again, if you want more information or specific requests, or it's, like, a good way to talk to the engineers that are working on the technology. We'll have a bunch of people there. All right. Hope you liked it. Of course, we have some Q&A.