Hello and welcome. A line from one of my favorite stories as a child. "We have so much time and so little to see. Wait, strike that, reverse it." Willy Wonka from Charlie and the Chocolate Factory. Let me roll up my sleeves here because we do have a lot to talk about today and I'd like to get started.

Let me give you a brief outline of what the story was. Basically, for the first time in a decade, Willy Wonka, an eccentric, reclusive chocolate maker, opens his factory doors to the public. Five lucky children who find a golden ticket in their Wonka chocolate bars receive a private tour of the factory run by Willy Wonka and his crew of loyal Oompa Loompa workers. Now, I'm not going to tell you who Willy Wonka is at our chocolate factory, but consider me your Oompa Loompa guide to the wild and wonderful world of font management on Mac OS. The factory doors are open.

Let's begin with a definition of font management. From a user's perspective, it consists of installing, activating, and deactivating fonts for use in any number of applications, including page layout programs, web browsers, and even the humble text editor. From a developer standpoint, it consists of a programming interface for accessing and modifying a central repository of font data.

Application developers use it to create standard user interface elements, like the Font Panel or the Font Menu. They also use it to map a user selection to a reference that can be passed to the graphics system to render text on the display or on other graphics devices like the printer. Now, the evolution of font management on Mac OS can be divided, actually, into two distinct periods. The first period is marked by a long series of incremental changes to a design that has remained fundamentally unchanged since the introduction of the Macintosh in 1984.

The second period is characterized by a transition, a transition to Apple-type services. It's a completely new font architecture that was designed from the beginning as an industrial-strength font database management system. Now, the key point of this session today is that this transition as of Mac OS X is complete. What you'll learn are the things as a developer that you'll need to do to take advantage of the features provided by this new font architecture, and also what steps you'll need to do to remove dependencies on the old model, which has completely gone away on Mac OS X.

Traditionally, the responsibility for managing fonts resides with the font folder and the finder, which in turn depend on the resource manager and the font manager to populate the database and manage that information. This design relies heavily on the Resource Manager, which was never intended or designed to handle the data retrieval and storage needs of most professional font collections.

The underlying implementation. They also implement their own auxiliary font management systems, all of which has to be synchronized with the central database through system patches, undocumented routines, and internal data structures of the Font Manager and Resource Manager.

Now, the existing implementation for managing the font files is a descendant of the original font desk accessory mover, which let users manipulate the contents of a monolithic system suitcase file. With the development of TrueType, fonts were no longer just bitmap fonts that could fit within the system suitcase files.

They became larger, more complex, and more numerous as people began to adopt them. When the functionality of the mover was integrated with the finder, the Font Manager and the Resource Manager were modified to create the illusion of a single system suitcase file from a multitude of font files located within the fonts folder.

Third-party developers, again, as I mentioned before, reverse engineered some of this implementation and figured out what was happening. And a lot of it was actually documented openly within Inside Mac. They created system patches that didn't necessarily work together very well. They duplicated functionality that was eventually developed within the system itself and were very fragile to changes within the implementation of the operating system. Some examples of these font management utilities include Adobe Type Manager, Font Reserve, Master Juggler, and Suitcase.

These font management utilities really came about because they were designed to address some of the inherent limitations in the system suitcase model. First and foremost, we have the limitation that all fonts must be referenced through font resources and the font suitcase file. An example of how this affects the regular user is Adobe Type Manager and the requirement that PostScript Type 1 fonts, even though they stood alone as separate outline files that ATM could render and display on screen, required a dummy font suitcase file with at least one bitmap file in there that was never really used to represent each outline font that was available. In addition to this, only a fixed number of files can be installed in the Fonts folder for use by the Font Management System on Mac OS. Most font management utilities work around this limitation by allowing users to activate and deactivate selectively sets of fonts.

Since these font resources must coexist in the resource chain as part of the system suitcase file, the Font Manager and Resource Manager become involved in resolving conflicts in the font resource identifiers and names. These changes, these are actually physical changes to the font resources, need to be communicated to the Font Manager through physical changes within the font files themselves.

If you've ever double clicked on a font suitcase file in the system folder and then took a look at it later, you might have noticed that the modification date had actually changed, even though you didn't do anything to it. Even though there's a user interface to actually move files in and out, a lot of times what happened was an ID conflict had actually been resolved and your file has changed.

There are obviously concerns about maintaining the validity of your font data because of this, so we want to move to a model where font data is not touched. And finally, any changes within the fonts folder are often not communicated to applications that are currently running. You would have to shut down your applications and restart them to see these changes.

Now beginning with Mac OS 8.5, the release of Apple type services for Unicode imaging. That's a mouthful. It's ATSUI for short, or ATS for the underlined subsystem. It introduced a text rendering engine and font management model that was designed to handle large collections of fonts and to handle multiple font formats and file packaging models.

The Font Manager and Quick Draw Text at that time were rewritten to integrate the ATS Glyphs cache, a central cache of information related to the fonts, and the Font File and Data Management system as an adjunct to the system suitcase model of the Resource Manager. On Mac OS 9.0, we introduced an extended set of functions to the Font Manager that allowed developers for the first time to make use of some of the lower level functionality of ATS.

By the way, one thing that I want to make clear is that this extended Font Manager functionality was available both on Mac OS 9.0 straight and in CarbonLib, the first release of CarbonLib. On Mac OS X, we've been busy porting ATS to a client server implementation, and we've been standardizing the programming interface in coordination with the other component frameworks of the operating system.

Now the main goal of the design of ATS was the replacement of the resource manager with ATS as the principal intermediary to the font database. The design also allows us to hide the implementation from third party developers by providing a programming interface for accessing and modifying the standard font collection.

By transferring the responsibility for managing the font files, parsing the font formats, and resolving name and identifier conflicts, We've allowed these modifications to be handled dynamically through internal data structures of ATS and Font Manager, rather than through exposed data structures through the Resource Manager. This information is made available to third-party developers through the Font Access and Data Management programming interface of the new Extended Font Manager and ATS.

Another aspect of this design is the font format independence and also for handling different storage models. What we've done is we've consolidated the way fonts get packaged. Essentially, font data may be stored in the standard, you might be familiar with this, SFNT is the tag that we used in the Resource Manager in the past.

A standard SFNT directory and data table model that was developed for TrueType and also has been adopted for the OpenType packaging model from Adobe and Microsoft. One last thing is that performance has been improved through the use of data structures and heuristics that are optimized for font management within ATS. And this works on multiple platforms and operating systems. We have support on Mac OS 9 and on Mac OS X.

In terms of implementing ATS itself, at the core of the architecture lies the open font architecture, which provides a programming interface and a protocol for communicating with these modular font scalers. Essentially, the font scalers are responsible for parsing and interpreting the font data that's specific to a particular font technology, like TrueType or PostScript. The font scalers participate in measuring and rendering text and translating the font data into a canonical format that can be used on different graphic systems.

The ATS Glyphs cache is shared by all clients of ATS and is designed for high throughput of the font data, especially in support of large glyph repertoires that are used in Asian fonts. The Font Database uses also references to font files that may be closed as needed in order to conserve valuable system resources and also just to allow you to handle these fonts without keeping them open like they were in the past in the Resource Manager.

There is also, thanks to this, no predefined limit to the number of font files that may be open or active and referenced through ATS at any single time. And finally, on Mac OS X, the client server implementation of ATS allows us to further reduce the load on the system by sharing more of the common data structures and common components.

Now, as you can see in this diagram, there's no sign of the resource manager in this particular implementation. This probably represents what you see on Mac OS X as of DP4. We have applications and utilities linking directly to an ATS client library, which then communicates to the ATS server, which in turn handles the low-level details of the font formats and packaging models on various file systems or even across the network.

Applications and utilities may also link to a particular graphic system like Quick Draw, which is represented through the Font Manager API, or Quartz to access their font data in a style that's closer to what is used on that graphic system. Underneath all of this, though, however, these graphic systems also are clients of the ATS server and parts of the ATS client library to make use of font data. This abstraction layer allows us to change formats or support formats, actually, as needed as things come along.

Now, a fundamental assumption in ATS is that all font data can be logically contained within one of these SFNT directory and data table structures. This happens to be, as I mentioned before, the native storage model for TrueType and OpenType fonts. As such, each font has a format identifier, a directory describing the data tables that are present in the font, and a collection of data tables.

The formats supported include TrueType and PostScript. And within PostScript itself, there are a multitude of variants. We also support classic PostScript outline fonts, the CFF format fonts, which are used in OpenType, CID keyed 2 byte font formats, or the font format for CID keyed fonts, and other legacy formats, including the OCF font format. That one we're actually working on right now, so it's not available in DP4, and we're working on OpenType support also.

One thing that we've had as a requirement was support for font file formats from other operating systems. An example of this is the Microsoft TrueType TTC or TTF data fork files. This becomes much simpler with the font management model provided by ATS. The storage models that we intend to support include, although these aren't completely guaranteed, of course, TrueType and PostScript font suitcases and font resources.

OpenType OTF and TrueType TTC and TTF files are something we are working on. And with the emphasis on PDF data structures and file formats within the new Quartz graphics system, we also are working really hard with the Core graphics team to get PDF embedded font data working properly. So that means a PDF with embedded data should work transparently on your Mac OS X system.

The programming interface, the ATS, lets application and system developers integrate many of the enhancements that have evolved over time. A lot of these features were provided through the font management utilities I described earlier, and also have been proposed or have been integrated in part in the Finder and Fonts Folder model. Now some of these features are actually not available at present time in the Finder. They include the ability to maintain fonts in locations outside of a single directory associated directly with the operating system, the fonts folder in the classic world.

Users also like to create and manage sets of fonts customized for different applications. This is something that you often do see with font management utilities. They also want to be able to open and close fonts while working in the middle of an application and have those fonts immediately available. They don't want to have to shut down their applications. And finally, some utilities also provide the ability to share fonts over a network, which we are actually providing transparently on Mac OS X through these APIs and the ATS architecture.

One last thing that we're working on is we're coordinating an effort with the high-level toolbox team and the app kit team to standardize on a user interface for managing fonts. This might integrate some of the features within the font panel that you've seen before and the traditional fonts menu that you're all familiar with.

At this point, I'd like to introduce my fellow comrade in arms from the type team, Julio Gonzalez, who will demo for you some of the features that ATS makes possible, and also some of the features that are actually already implemented in DP4 or are planned for the retail release of Mac OS X.

Good evening. I wanted to start by talking and showing you the different locations for the font directories in OS X. The first location the ATS system knows about is the system library fonts location. Here we have the fonts that are required for the basic operation of the operating system, plus some fonts that traditionally were shipped with.

Next directory that the ATS system knows about is the local fonts directory. This location is the ideal spot for font collections to get installed into, not so with the system directory which is exclusive for Apple's use. The next directory it knows about is the Network directory. Unfortunately, I'm not on the network, I can show it to you, but this is the ideal spot for, say, a company-wide font that is used in internal documents.

The last directory that it knows about is the User Fonts directory. Basically, these fonts are only available to the user that is currently logged in. But the beauty of this directory is that if the home directory resides over the network, as you log in on a different machine, the fonts go along with you.

Now, let me show you some of the new features that we have on OS X. This is the current version of Simple Text that is shipping with the CD that you all received. It's basically a carbonized version of Simple Text. It doesn't do much as far as using the new API. So, if we look at the Fonts menu, this font menu is built using a pen rest menu. This is what you're all familiar with. It's just the assorted list of fonts that are currently installed in the system.

Now, I've taken the same version of Simple Text and modified it to use some new APIs that were introduced in CarbonLib 1.0 that allow you to create a new menu. One of the advantages is that you can have a hierarchical menu. It's more compact, it provides more information, so here you see the sub-menus which show you the weights and stresses that accompany this font family.

Another feature of this menu that is not readily seen is automatic font activation. What do I mean by that? Typically on Mac OS 9, say, if you wanted to install a font, you would install it into the Fonts folder. Any running application would have to quit and restart for you to be able to see or use it.

Now, if I go back here to my disk, Pick up a font, drop it into my user's font directory, and make sure that it got copied there. That's the user's font directory. Go back to the modified version of Simple Text. Hello? Oh, not the font that I wanted to use, but let's pick up a nicer one here. Yeah, sorry about that.

I picked up the one below, or the one above. So if we head back, let me unclutter some of the mess here. There it is. So, we didn't have to quit the application in order to see the font, and not only that, of course, we can hopefully use it.

So that's an improvement over what we've had in OS 9. Another thing that you can do with this activation is what Robin talked about is you can activate now fonts anywhere outside of the scope of what the system knows to look at. So that gives us a few advantages. For example, applications that want to ship with their own fonts.

Typically, applications have had to install fonts in the fonts folder or have shipped with the font suitcases inside of the resource fork of the application. That second option, of course, is not doable under OS X because we've divorced from the resource manager altogether and we no longer look at the resource manager for fonts.

You can still install the fonts into any of the known locations, the user, local, or network directories. Which, by the way, you can get at using Find Folder the same way that you would under classic Mac OS, just by calling Find Folder with some new constants that are provided.

A better way would be to ship the fonts that the application wishes to use along with the application. So that's what I've done with this version of Simple Text. If I go back to this and show the version of simple text, I have a font folder that lives right along it. It's got a chest font here that I'm going to demonstrate.

The directory is just at the same level as the application as it launches. It looks for this font's directory in the same spot as it is and activates a font. So if I go back here to the modified version of Simple Text, Here's that font that has been activated, so I can go ahead and use it.

So that is a cleaner way of doing it, but let me just talk about this a little bit more. This is not the most clean way of doing it. Here the finder is showing us the simple text application as an icon that we can double click on. In reality, this is a package, a directory structure. Inside of this structure is a contents directory, for example. And this would be the ideal spot to put your fonts directory. And that way, as you copy the finder around, move it around to another location, your fonts would be copied alongside it.

So now, how about activating other fonts on the system? I have a tool here that allows us to do just that. Let me bring it up. It just shows the glyphs that the current font needs or has. Let me also bring up the font panel. This is the standard UI on the Mac OS X for the font panel. And these are the fonts that are available under it at the moment.

I have a menu item here that will allow me to activate any directory that I have on this. I have here a set of demo fonts. Please watch closely the font panel underneath it as I activate that directory. Here we go. We have now a bunch of fonts that we can now use. This was a font that was not there. It updates in the background. Apple Garamond was also not there.

So you can imagine, you know, now we can, you can have a user have a set of directories and organize their fonts in whatever way they wish to use them and you, as a developer, provide a UI that lets them pick any of these folders to activate or deactivate on the fly.

For the purposes of the demo, when we use the activation routine that Robin is going to talk to you about in a minute, you have two options. You can activate the font locally so that only this application sees it, or globally. We chose to activate them globally. So as we quit, This demo application and go back to our simple text application. We should be able to see them and here they are for us to see.

The last thing I want to show you is some of the formats and packaging that Robin talked about that we now support. Some of these are, of course, work in progress. So let me just show you some of the The fonts that were in that activate demo fonts that I just activated. This font right here are Windows TrueType fonts. In fact, I downloaded this from the Microsoft website. And it's standard TrueType Data Fork font. So no resources whatsoever in here, SFNTs, you name it.

This font here is an open type font, a Japanese open type font, so I'll go ahead and make use of them. Oh, before I forget, notice also, if I go back to my version of Simple Text, This font right here are, both of them are PostScript fonts. There is no ATM installed in this system. This is part of the Mac OS system now, Mac OS X system. So let me go back and show you some of these fonts. This is the TrueType font from Microsoft.

So it does operate. Hopefully you can see it. And now I can go ahead and try that Japanese OpenType font. Excuse my Japanese. Hopefully it will come out right. Here we go. With that, I'll hand it back to Robin and she'll talk some more about all of these wonderful APIs that I've been using here for the demo. Thank you.

Thanks, Julio. So let me reiterate at this point. The key point of this session is that on Mac OS X, we've completed the transition to the ATS font architecture. As Julio mentioned, the resource manager is not really in the picture anymore. Now ATS organizes the font data in a two-tier hierarchy consisting of font families and fonts. A font essentially represents a component of a font family that is differentiated by stylistic variation or stress like italic or weight like bold.

The font family is a reference to a collection of fonts with the same design characteristics. This is kind of a definition that most of you are probably familiar with in terms of computing and displaying text on a computer. This font family reference, it's compatible with the routines of the Font Manager in Quickdraw Text and may be used wherever a standard Quickdraw font identifier from the older days, including the text font function that you're familiar with in Quickdraw and the TX font field within the Quickdraw graphics port.

However, it cannot be used to access information from a FOND or font resource handle through the resource manager routines. In addition, a font family reference does not imply a particular script system, nor can it be mapped through some arithmetic magic to a particular character encoding, as was true in the past.

Each component font associated with the font family is identified by an opaque reference to a single object registered with the font database. This font reference consists of the individual outline and bitmap fonts that form in combination the font family. Within the ATS programming interface, there are also compatibility routines that let you map one of these newer references, or at least the font reference, to an old style font family ID and a traditional quick draw style bit set.

Many of the features that I'll be describing in this section are implemented already in the extended programming interface of the Font Manager that was introduced with Mac OS 9.0 and the first release of CarbonLib. On Mac OS X, particularly if you're going to be working within an environment that's based on the Quartz graphics system, like the App Kit, you have the option of linking directly to the new ATS framework. This is where the actual implementation of ATS resides on Mac OS X.

Now there are four basic tasks that the programming interface needs to provide. And this is available, again, on CarbonLib and Mac OS 9 within the Font Manager and on Mac OS X through the ATS framework. They consist of the ability to enumerate or search for font families and fonts. Accessing information and data contained within the font families and fonts. And a set of database related routines, the main one being the ability to activate and deactivate fonts. And finally, we have an implementation of a basic font menu, as Julio showed you earlier, that replaces the Append Res Menu implementation that was very resource manager centric.

So as for enumeration, these routines, again, allow you to iterate and search for font families and fonts using a model that's thread safe and compatible with the preemptive multitasking environment of Mac OS X. Four routines are usually provided. There's one to create a font or font family iterator object that maintains the state necessary for high quality data. There's a function to iterate to the next item, and there's one to reset the state of the iterator object, and one to dispose of the iterator once you're done.

One additional feature that we provide on the ATS framework is a utility function that's similar to what you see in the Core Foundation Collections Library. Essentially, it's the ATS font apply function. It wraps everything up so you don't have to deal with iterators directly, and you can simply pass in a callback routine that's applied or called for each item that's iterated.

Now, here's how you create an iterator to step through all of the fonts accessible to your application. It's essentially wrapped with a create and dispose function. Within it, there's an inner loop that iterates through all of the fonts. It returns the font reference that you can use with any of the accessor functions within the library. Now as for the access routines, what you'll want to avoid doing is using the Resource Manager routines to access the data stored in the traditional font suitcase files. These resources include the fonts, the F-O-N-T's, the fonts, NFN-T's, SFN-T's, and LWFN's, a whole alphabet soup of resources.

The resource-based semantics of the old Font Manager will still be available because we didn't blow away the old Resource Manager routines. And you'll be able to return some values, but it will not be set up the way you're used to with the system resource chain and all the fonts available globally. Instead, what you want to do is use the iterator and the apply functions and also use the ATS accessor functions that are also available in a slightly different form within the extended font manager.

In terms of the interaction between the Font Manager and the graphics system, one thing you should avoid doing is depending on FM swap font and the traditional resource-based Font Manager data structures to access information such as metrics and other metadata about the fonts. An example of this on Mac OS X is within the FM output structure.

There is a font handle field that currently is going to be set to nil in most cases since a lot of this font data is not going to reside within a resource handle. There are other data structures that you're probably familiar with that also have similar resource handle pointers or handles to resources that are probably going to be set to nil or will definitely be set to nil in almost all of these cases.

The way you get around this, of course, is to use the accessor function that we provide through ATS and through the extended Font Manager. They are set up so that you'll be able to access information that you would normally have gone to a font directly or to the font handle to retrieve this information.

And we're currently working with the various graphics systems and the teams for the Quartz and Quick Trial graphics systems to integrate these font family and font references into the system as accessors. So you won't have to do any sort of conversion back and forth. You can just use these natively within those components.

I'll say this one more time: Don't use the Resource Manager. For activation and deactivation, people in the past have patched the Resource Manager and Font Manager to get the work done. They have intimate knowledge about the way the resource chain is set up and how fonts are inserted and removed from that chain. That will no longer work.

As of CarbonLib 1.0 and Mac OS 9.0 and on Mac OS X, we provide functions that make this so much easier for you. You should be using these. We have a whole suite of these. There's not just basic activation and deactivation, but also ways to pass in the information, whether it's a file or within memory.

One additional thing that I like to explain is we also provide a mechanism for notification. It's very simple in this first release, but essentially it consists of a generation seed value. It's a global value that's stored in the ATS server that gets updated whenever anything happens to change the state of the font database.

This means any operation that can add, delete, or even modify the fonts or font families that are stored in the database will trigger a change or an update to the seed value. And also, any font family or font that happens to be touched within a particular transaction will be tagged with the current value of the generation seed. So there are accessor functions that allow you to retrieve this information and compare it against a cached value that you store within your application to see what happens to the database. This provides the core functionality for the way the updated font menu has been working.

So, on Mac OS X, as Julio described earlier, you cannot embed a font in the resource fork of your application and assume that it's automatically registered with the Font Manager when the application is launched. Instead, what you want to do is you want to locate some predefined place. If you've actually carbonized your application already and have one of those packages that Julio showed to you, one of those .app directories, then you can use the CFFundle routines that are available in Core Foundation to actually locate one of the particular subfolders where you can place your fonts that's carried around with the application whenever a user copies it and pass that particular piece of information, the location, as a file spec or a file ref or even a path name to the ATS routines to activate the fonts contained within it.

From that, with the ATS framework, you'll be able to use an opaque container reference to find the fonts that are available or that were registered with the database from within that container or that file or memory location even. One thing I should note that Julio mentioned earlier, he actually stole some of my thunder, was that we have the ability when activating a particular container to determine the context, whether it's local to the application or global and system-wide.

And so that's going to be one of the parameters that you'll be able to pass in. The default behavior, of course, is to make it local to the application and safe so that when an application is normally shut down or crashes even, those fonts will be removed from the system.

The final task that the programming interface provides or enables you to do is a basic font menu. I think I'll say this one more time. Don't use the resource manager based routines to do this. Instead, what you'll use are a standard set of functions that were distributed as of CarbonLib 1.0 in the Menu Manager to create this basic font menu. And that's actually what Julio was using within his eSimpleText that he was demoing.

So they provide just a few functions that allow you to create and dispose of a standard menu, to update it automatically based on this generation seed and the current state of the font database. And one key item: Since the implementation is radically different, or it is different anyway from the old Append/ResMenu menu, We provided a function that allows you to map a user selection to one of these new font family or font references.

So here's, real quick, how you'd actually create one of the basic font menus. It's almost identical to the old Append Res menu, except for the fact that if you look down below, there's a hierarchical font menu option. So if you pass that in, you'll actually get one of the fancy new hierarchical menus. It's not spectacular, but it gets the job done. If you wanted to, you can actually implement your own version of a font menu using the standard accessor and iterator functions.

Now this is what's more interesting. So given one of these hierarchical menus, which is different from the old append res menu style where you can simply take the item text and use the Quick Draw routine, get FNUM, to map it back to an ID that you could pass through the Quick Draw graphic system.

Instead, we provide you this function, Get Font Family from Menu Selection, that takes the menu handle and the item that was selected and maps it back to a reference and a standard Quick Draw style that then you can use with Quick Draw. So one of the benefits of this is that in the future we could change the implementation so that the menu items are no longer a standard Quick Draw font name. We could actually make it so that they're customizable. Or we can change the font name. Make it possible to have both a PostScript and a TrueType version of Helvetica present in the same font menu and allow users to distinguish between them and use them as they want.

So to wrap this up, I'll say this one more time. Don't use the Resource Manager to do your font management. Begin developing to the new extended Font Manager programming interface that's available with Carbon. Also, as of DP4, you'll be able to preview the programming interface that we have in mind for the ATS framework. Now, just a caveat. On DP4, you won't be able to link against these functions and you won't be able to use them. Just take a look at the header file.

It's called ATS font.h and it's included within the ATS framework itself. If you know the structure of the new framework hierarchy, basically each of them is a modular package that represents a component in the system with headers that are included within that package. So again, preview those interfaces and see what's up, what additional features we'll be providing and exposing through the ATS architecture.

Here are a couple other sessions that you might be interested in. The text session already happened earlier this morning and a lot of you might have already gone. But hopefully, I'm not sure about this, that they'll have some sort of streaming capability or something to review the lecture.

There's also the Quartz session on Friday that you'll be interested in. This goes more into the graphic side of things and it's specific to, of course, the Quartz system. And finally, on Friday also, there's the traditional international and text feedback forum that I'll probably be at and so will my colleagues. And you can talk about all kinds of other related topics in the text field.

On the web, if you don't want to get up and talk in a meeting here at WWDC, you can actually go and take a look at the Texton International website for our DTS technical documentation. And I'll give a plug to our fellow group in the Apple Fonts group, which actually creates the fonts that we ship on the system and the tools and utilities that are used to develop them.

And a final quote from Willy Wonka: "Invention is 93% perspiration, 6% electricity, 4% evaporation, and 2% butterscotch ripple." Think of it this way: We've already gone through all the perspiration for you, so one additional set of changes to your application and your utilities will give you that extra magic that you'll see from our chocolate factory. Thank you very much.