Hi, I'd like to welcome you to session 128, Font Management on OS X. The font management on Mac OS X has changed a lot compared with Mac OS X and the font formats we supported. I think we're going to have a great session today. We have actually an extra guest, a special guest, I should say, from Macromedia.

We'll talk about his migration from Mac OS X to Mac OS X and the APIs he used to replace the whole course he had on Mac OS X and go around the limitations of a resource manager. So let's stop now. I'd like to introduce Nathan Taylor, who's actually a software engineer in the Type group, who has been working on the Font Manager for Mac OS X.

Alright, well, thank you for the introduction, Xavier. Well, I'd like to announce that we've shipped Mac OS X. We've done a lot of work here getting it ready for you guys. And we can't wait to see what great applications that you will create for this platform. Today's agenda is an agenda for answering questions. We've received many questions along the road, and we hope to answer a few of them today.

I'm going to start off by going into the inner workings of ATS and the Font Manager on OS X. Then we will go into programming examples and getting into the programming interface and getting into the nuts and bolts of the APIs that you will be using. And finally, we'll have a real-life example to spice things up.

In development of ATS for Mac OS X, we had several enhancements that we wanted to make. First off, we created a specialized database for handling fonts and font data. This obviated the need to use the Resource Manager and as a result we get better performance from taking advantage of Mac OS X's kernel features.

Additionally, from this approach, we can enhance scalability. We can now handle many more fonts and many more font formats. Additionally, now there is no longer an upper limit to the number of fonts that can be installed in the system except for the RAM that a user might have installed.

In doing this, we wanted to improve the extensibility of the font system on Mac OS X. and we also mentioned before we support more font technologies and font packaging formats. Additionally, we have support for plug-in font rasterizers so we can create new font rasterizers to support such things as stroke-based fonts in the future.

A major design goal of this rewrite for Mac OS X was to provide a consistent programmer interface. This way, developers who want to use fonts don't have to know the specific details of the font formats that they're going to be using, and they don't need to be wizards of the Resource Manager. Another major feature is that we feature non-invasive file access. You can be assured that when you install fonts from a CD, those fonts will not be modified.

This graphic here shows an outline of the ATS client hierarchy. As you can see, ATS lies at the bottom. It's the foundation for all the text handling in Mac OS X. There are different frameworks here that you can take advantage with your application and they will all call into ATS to get font and font data.

One of the major questions we have received most frequently is what type of font formats do we support? We support the TrueType font technologies in various packaging formats. We support the standard Macintosh resource-based font suitcases that you know from previous versions of the OS. We also support a new format, the D-Font format, which is a data fork packaged font very similar to the resource fork. We also support now Windows TrueType fonts so you can install TTF and TTC fonts and they will just work in Mac OS X.

Thank you. Additionally, we support a wide variety of PostScript fonts. We now support the up and coming standard OpenType from Microsoft and Adobe. And we also support the Type 1 format that you all know from Adobe Type Manager. Finally, we have support for Asian fonts using the Character Identifier keyed PostScript fonts.

Another frequently asked question is, where should fonts be installed in the system? These areas in the system are listed in precedence order here and we use the precedence to resolve font duplicates. We consider these areas domains in the system. The highest precedence domain is the user domain. It's in the user's home directory. They have a library fonts folder. Users can install any fonts they want in this directory. They will take precedence over other fonts and the user will get to see the fonts that they intend to use.

Additionally, the next domain in the precedence chain is the local domain. This is where a system administrator can install fonts for use by all users on a system. It is also where we encourage developers to install application-specific fonts and fonts they decide to share between other applications. Another interesting domain is the network domain, where a corporation can install a corporate-specific font. At Apple, we install Apple Garamond TrueType in the network domain and use it on all corporate systems.

The fourth domain which I have highlighted here is the System Domain. The System Domain is where Apple installs the system fonts. We recommend that this domain not be used for installing third-party fonts or application fonts. Finally, we also support fonts from the standard Mac OS 9 system folder These fonts will be picked up from a previous install of Mac OS 9 and used with all Mac OS X applications.

There is a caveat to this though. The classic applications that you run will not get to see other Mac OS X fonts. They will only see the fonts that are in the classic system folder. This system folder changes when a user changes their specific classic folder in the Preferences panel. and one other thing I'd like to note, all of these domains are scanned and activated when a user logs in.

Another area of concern is where can developers install fonts? We are actually very flexible. Fonts can be installed in almost any directory on the system and programmatically activated from an application. However, there are some recommended locations that you install your fonts. One place you might want to consider if you are a vendor that ships multiple applications that wants to share a set of fonts, you may want to consider making an application library directory inside of the local library or a user's library to share fonts between your various applications.

More specifically, if you require a specific font for your user interface, you might want to consider installing the font inside of your application's bundle. This can be programmatically activated locally only to that application and your application will be assured that it gets the font that it needs for its UI.

Additionally, we support activation from memory-resident fonts and also application from resource forks. If you insist on bundling a fork inside your application's resource, you can activate that particular file and it will activate the font right from the resource fork. I'd like to make one note. Fonts that are activated programmatically take precedence over the fonts that are activated from the multiple domains. And above all, the local domain, when you activate a font programmatically locally to your application, you will be assured that you will get that font.

Font installation on Mac OS X is as simple a procedure as it was before. It's a simple matter of locating the font directory that you want to install the font, dragging the fonts you want installed, and dropping them in that folder. Deactivation works very similarly. Just take them out. These directories will get re-scanned when you launch your application. Also, they get scanned when a user logs into a system. One caveat to this is that running applications will not see an update of the directories until another application is launched. When this application is launched, it triggers a re-scan of the directories.

Since we have multiple domains for installing fonts, there's the issue of handling duplicate fonts. And as I mentioned before, we handle these based on a precedence ordering of the domains. The user domain takes precedence over all the standard domains and programmatically activated fonts will take precedence over fonts in the standard font folders. Conflicts are handled in a slightly different manner. We handle font conflicts by synthesizing an entry in the font database. This is to facilitate the fact, as I mentioned before, that we will not modify the files and support non-invasive file access.

Font selection on Mac OS X works just like it did before. We have rewritten the APIs for creating the standard font menus and they act as clients directly to ATS. Carbon developers using the Carbon framework can present their font menu in two manners. You get a standard, flat font menu as users are used to for Mac OS 9, and then there is a new, more compact, hierarchical format font menu.

If you are writing a Cocoa application, you get the benefit of the new AppKit font panel. This font panel makes it easy to access your fonts in large collections, manage your collections, and also gives the user an easy way to visualize the font family, style, and size that they are currently using.

The printing system on Mac OS X is a major client of ATS. It uses ATS to convert fonts from the standard display format to formats appropriate for embedding in PDF documents or downloading to a printer. The printing is handled through a standard dialog in all Carbon and Cocoa applications and uses a PDF as an intermediary throughout the entire process. Fonts are streamed from ATS and embedded in this PDF file. And we also do sub-setting of the fonts for this. Because the fonts are embedded, these PDF files can be shared between platforms and viewed with a standard PDF viewer and expected to display as they should.

Okay, I'd like to take a moment to discuss what I'll be showing in a brief demonstration here. I will illustrate the standard font directories on Mac OS X. Then I will illustrate the methods for selecting fonts, printing and printing to PDF and exchange of PDFs. And finally, an application I have that does a local activation of a specific font.

Okay, first off, I'd like to show you, this is the classic So this is the classic domain where classic system fonts are from. You can see it's coming from the standard Mac OS 9 system folder that's installed on the system. Additionally here, this is the system domain where you can see where we have our system fonts that are stored as D fonts and OTF fonts.

Additionally, I have the local domain here where system administrators will install system-wide fonts for use by all the users of a system. and finally, users have their own font folder inside the user home directory where they can install any fonts they choose. Font installation, as I mentioned, is a simple process. I have here a collection of multiple formats of fonts. And I'll install some OTF fonts here, some PostScript character identifier keyed fonts. Standard PostScript Type 1 fonts and finally a Windows Troop type font in TTF format.

Sorry, the command key on the left is broken on this keyboard and I keep forgetting it. OK. As I mentioned, I just installed the fonts here and you can see that they are not actually activated inside of this menu. If I launch a new application as I'm doing now, these fonts will be activated. The directory will be re-scanned and you can see an example right here. I have Arial in the TTF format, the Windows format I just installed, and it's a simple matter to use it. I can select my text and change to it.

Now I have two demo apps here. This one first shows the standard flat Flat Style Font Menu in Carbon and then I have a new one that I have implemented with a Hierarchical Style Menu And then, as I said before, Cocoa applications get the benefit of the new font panel where it's easy to see the family, typeface, and size and change this to a font I activated. We'll go with Tekton Pro, Oblique.

Now, as I mentioned, printing is a simple process presented in a standard dialog. I can choose to print. and preview this directly, which will generate a PDF. The fonts are streamed to it, subsetted, and embedded in the PDF document. This document now is savable as a PDF document.

Save it to the desktop, whatever. And then I have one I previously created, which can be shared cross-platform in this example with classic using Acrobat Reader 4. Finally, as I mentioned, I wanted to show an example of locally activated fonts. This version of-- of Simple Text with the hierarchical menus has a copy of Apple Garamond TrueType embedded in the applications bundle. I call centered APIs to locate this and activate it. It's activated locally only to this application and is not available to other applications.

As you see, if I go to this other simple text here, there is no Apple Garamond. There's an Apple Chancery that came from the classic domain. And additionally, TextEdit doesn't have it either. That concludes the demonstration. I'd like to introduce Julio González, a senior software engineer in the type group. He will go into the programming interfaces of ATS and Font Manager on Mac OS X.

Thank you, Nathan. I'll be talking today about basically the APIs that are available to you for font management and some of the issues related to OS X. I'll start with the API sets, some concepts, tasks, especially from the point of view or from the angle of all the questions we've received as people have been bringing up their applications to run OS X. And finally, I will touch up on some of the performance issues that might bite you, especially if you're coming from Mac OS 9.

Before I get into everything, while I was writing up this presentation, I just decided, let me take a look at what font management used to be. And I opened up inside Mac, Volume 1, and that's what I came up with. There were seven simple APIs. Boy, do I miss those days. A lot less work, but we've come a long way, especially with 10. So, let's get into it now. One of the issues or things that presented some confusion as we introduced Mac OS X is that there are two set of APIs that you can use for font management.

The first one being the Font Management, the extended Font Management set of APIs that are present on 9. They're also available to you or we export it by CarbonLib and also of course available in 10. But then there's a new set of APIs that some of you have seen that are part of the ATS framework. It's the header is ATSfont.h. And I want to make mention of this. This is a new set of APIs that we've created and are only available under Mac OS X. We have no plans at this point to take that back to CarbonLib or Mac OS 9.

The intent of this API was to fill in some of the gaps that were created as we moved to Mac OS X and try to address some of the system differences. Moreover, there are opportunities here in this new set of APIs to address some features that we can no longer address under the Font Management set of APIs. So once again, this is only available on Mac OS X.

So, let's get started with some of the programming concepts. First one being the font family reference. Hopefully most of you are aware of that. It's basically an opaque reference to a collection of fonts that share the same design characteristics. Then there are font references. Basically these are opaque references to specific strike or specific font in that font family. Then there are containers. Containers are opaque references to where the data for the font resides.

This could get a little ambiguous as we now support different file formats for the fonts. So where does the data really live? We like to keep that as much of it hidden from you as to prevent some confusion. This is something, for example, that we'll try to address in the new set of APIs. Finally, there's the concept of generation. As we moved away in Mac OS X from using the Resource Manager to keep track of all our font data, we created our own font database.

In fact, this is also present in 9. So, in order to keep track of when the data change or when fonts were added or got deleted, we have a generation, a generation seed that we can keep track of. And there are APIs where you can get the seed. So this is how you can tell when something has changed in the database. So, yes, we know you still have to pull. Notification hopefully will be on the way.

Okay, the next one is the data types. This has definitely caused some grief for some of the developers out there and we'd like to take some time now to clarify this. Basically, you have data types for specifying font references and font family references. And for the font references, we have the FM font and the ATSU font ID and the ATS font ref.

FM Font and ATSU Font ID are basically the same thing and can be used interchangeably. However, ATS font refs are not the same, even though at this moment they are the same and you can get away with it, but they are not intended to be the same thing.

If you use them interchangeably, you will surely run into trouble. Same thing goes for the FNFont family and ATSFontFamilyRef. Here it's a little bit more obvious as the FNFontFamily is the usual signed 16-bit number, basically the resource ID, whereas the ATSFontFamilyRef is an opaque 32-bit data type. Once again, they cannot be used interchangeably.

So next we'll move into some of the programming tasks that I'd like to cover. And again, these are tasks where people have been having troubles or questions as they've come up to OS X. Storing font references, data access especially, enumeration, that is how to find out what fonts are installed in the system, conversion compatibility, how to go about activating fonts and deactivating them, and finally how to go about selecting the fonts through the UI.

Storing font references. We get asked this question year after year. What is Apple's recommendation to store font references? Well, we're still at the same stage. We have no strong recommendation on what to do about it, but let's examine what people have done in the past and some of the caveats here. Some applications have gone in and stored the font family ID as a font reference.

That worked mostly fine on 9S confined to one particular system. But on 10, that could break even quicker. Reason being, as Nathan mentioned before, we no longer modify font files as we install the fonts into the system. As we used to do in 9, if we found that there was a resource ID conflict, we would go ahead and modify the font or the suitcase before it got placed in.

On 10, we no longer modify the files and what we do is we do create a synthetic resource ID entry, if you will, a font family entry. So depending on what fonts you install or you install new fonts, this ID is no longer guaranteed. So it's a really, really bad idea to store a font family ID as a reference.

So you can still do it if it's applicable or enough for your application, store the font name as a reference. But better suggestions, for example, the Quartz engine stores PostScript's names. At SUI, or sorry, not at SUI, but MLTE, it stores a combination of font names. You can get creative and pick up a different set of names, store them all, and then as you open the document later on, try to match on the font name. However, as far as the API sets that we provide, the best way still to store a font reference, if you want to be guaranteed of the font that you stored as the same font that you're going to be using, is to use a font sync reference.

Okay, next point is data access. Let's examine what we do typically online regarding font data access. Typically we use heavily the resource manager to get at the data that we needed. With 10, we moved completely away from relying on the Resource Manager to get our data. So this is a big issue now. The same goes with low memory globals.

On 9, they were truly globals. On 10, they were per application, per context. Not that you care that much. But there are some caveats about low memory globals. As we stepped away from using the Resource Manager to keep our data, Some of the low memory globals that we have store data references which were resource handles. So if you were to access those low memory globals and expect to see a resource handle there, you'll be up for a surprise. Whenever possible, we store nulls in there to sort of warn you that this reference is no longer applicable.

Another thing was that on 9, any font file or any access to a font that you had, you were guaranteed that the font file was open. Not so in 10. Even though through enumeration you can get at the font, the font file might not be open. So, what is the recommended way for you to move on and get at the data on the font? It's to use some of the accesses that we've provided in the font management set of APIs. For example, the FMGit Font Table, FMGit Font Table Directory, FMGit Font Container, and there are others. Here's a preview of some of the data accesses that APIs that we provide in the ATS font set of APIs that might be useful to you at this stage.

For example, the ATS font Git Postscript Name, which will return to you the postscript name and you don't have to go dig it from the font or anything like that. And given the right options, it will also return to you the CID name. Also, there's the ATS font Git Horizontal Metrics and Git Vertical Metrics, which will return to you some metrics information that you might have otherwise gathered from the width tables or FM Swap Font.

So, now, what if we don't have the APIs right now to get at the data that you want? For example, one typical request that we got from developers was, "How do I get at the font? I still need to get access to the font and process the data in my own way." So, this is something that we'll have, hopefully, later in the future in the ATS font set of APIs, but you can do that with the set of APIs that we have right now. First, presumably, you're going to be starting from a font family reference and also, hopefully, a Quick Draw style or weight. So, from there, you can call fmgit font from font family instance and get a font reference.

Given the font reference, you can call fmgit font container, which will give you the FS spec. And next, you've got to call open resource fork. Again, you've got to call it because the file might not be open. It's not guaranteed to be open. That in itself might fail because it might be a defont, so you'll need to call the appropriate Carbon calls to open the data fork resource font.

Once you do that, you can get the font family name and from there, call get one name resource to get at the font. Notice I used the name. We did not use the font family ID to get at the resource. Reason being, the font family ID might be a synthetic font family, so you're not going to be able to get at the resource that way. get at the resource that way. So please use the name.

Okay, the next question is, how do I find out what fonts are installed in the system? Before it was very simple, you could enumerate through the Resource Manager and it'll give you all the fonts. Not so under 10. So there's a couple of iterator APIs that are available to you, both on the font, FM font set of APIs and the ATS font set of APIs.

With this, there is an issue that developers had in reading the documentation that is up on the web. Basically, the documentation stated that neither one of these iterators would return to you all the fonts that are installed in the system. That is mostly true and it's a little bit confusing.

Where that statement comes from is that on 9, you can't get all the fonts installed in the system simply because on 9, we do not support data fork fonts. And our conflict resolution and duplicate resolution is not as strong as it is on 10. However, on 10, you can get all the fonts that are installed in the system.

If you call a font reference iterator, you get all the outline fonts only. You will not get any of the bitmap fonts. Basically, because if you try to use a font reference in a bitmap font in some of the APIs that we have there, you basically get an error. There's no sense in getting a table for a bitmap-only font, for example.

However, using the font family iterators along with the font family instance iterators, you'll be able to get at every single font and font strike that is installed on the system. Whether it's a data fork font, a bitmap font, an outline font, whatever. You'll be able to get at every single one of the fonts that are installed.

One nice thing about these iterators is the filters. There's some set of filters that you can use. We provide some standard ones such as the technology filter. And you can tell it, "Please give me all the True Tribe fonts or all the Type 1 fonts that are installed." The container filter, so given a container reference that you might have obtained elsewhere, give me all the fonts or font families that belong to this container. Generation, which you might find useful if you're keeping track of the generation to let you know what fonts got installed, just got installed on the system. And also we provide you with some callbacks that you can use to filter the fonts as you go along.

So here's some example on how to get every single one of the strikes on 10. You basically first call fmcreate font family iterator, which will return an iterator cookie to you. You use this cookie to call fmgetnext font family, and it just basically gives you every font family from that point on. Once you have the font family, you can create a font family instance iterator.

This iterator will return to you each one of the weights that are part of this family, along with any duplicates that we might have resolved. So you'll get every single font that got installed. At the end, you just dispose the iterators. One thing to note that in the while loop, we check for the errors here. One of the errors that you might get as a valid error is that the iteration is done.

But another interesting error that you can get is that the font object database has changed. So as you're iterating, you can get note of this error and decide whether you want to make sure that the database has changed and just proceed. Or you can reset. There's a reset call that you can call and reset the iterator and start all over again.

Conversion APIs. At the moment, we only have conversion APIs that can take you all within the FN Font Management set of APIs from a font reference to a font family reference, a font family instance reference. There is no way at this point in time to go from An FN font ref to an ATS font ref and the same goes for the ATS font family ref and FN font family ref. That will be forthcoming.

Compatibility, we have that in the layer of the ATS font and it's basically a meager attempt actually to just get some compatibility with the Quick Draw space. And there will be more in this arena too as we try to make it easier for you to transition from the FM font management set of APIs, which is for the moment the recommended way to do things, to the ATS font set of APIs, which will be in the future the right way to carry on if you're developing exclusively for OS X.

Another interesting API here is the ATS font get file specification, which has sort of a counterpart on the FM side of things. I think it's FM get font container. The ATS font get file specification takes a font reference and in general font references are references to outline data. So this will get you directly to the outline data as opposed to say in an LWFN font it won't point back to you at where the suitcase is. Thank you.

Okay, now how do I go about programmatically activating and deactivating fonts? Some of these APIs have been available in 9, the FM Activate Fonts and FM Deactivate Fonts. You can activate a single file or a whole directory of files. Please note that if you pass in a directory to get activated, we only activate the files that are in that space, in that directory. We don't go and recursively activate all the fonts in the directories.

In the ATS font side of things, there's a couple of nice ways to activate and deactivate font files. And it has a nice feature, the ATS font activate from file specification that you can specify a context. So you can, like Nathan showed in his demo, if you make this call, you can specify a local context so that that font is only visible to that running process or application. Lastly, there's the ATS font activate from memory, which given a stream and if you give us some hints about the stream, we can activate the font for you. This is heavily used by the Quartz engine to render embedded PDF fonts.

So here's the demo and this is basically some source code for what Nathan showed in his demo. Say you were an application, a 9 application that is quickly coming up to 10 and you still have your fonts as part of your resource fork. Well, in 9, as the resource fork for the application opened up as the application launched, the font immediately became part of the resource chain and it became available or visible for the Font Manager and actually to all applications that were running.

In Tencent, we no longer rely on the Resource Manager. If you wish for the font to be activated, you must programmatically do so. One way to do this is you call the Process Manager APIs and whatever else to get at what is the file spec for the currently running application, your application. Once you have the FS spec, you can call this API, ATS Font Activate from File Specification.

Pass that off the application file spec. You can specify the context. If you for some reason wanted it to be global, you can specify that there, but preferably or most of the time it will be local. And it will return to you an opaque container reference. Lastly, if you care to do so, you can find what fonts are part of this container by calling ATS Find Font from Container. No, the preferred way actually to, as Nathan said, to ship fonts for your application would be to just place a directory full of fonts in your application bundle instead of just having it be part of your resource work. It's just a little cleaner.

Now, selection. This is another question that we've been getting from our developers on the Carbon side, is how do you go about selecting fonts? So, the answer is, as Nathan showed, at least from the Carbon side of things, is that you have to still use and depend on the Carbon set of APIs, which means that you don't have access to the font panel that Cocoa has for you. That will be forthcoming too, and it's a high priority.

So how do you go about having a font menu intent since we no longer use a Resource Manager? Well, you can still call a pen rest menu and it will do the right thing. It will create the standard flat font menu that you all know. But it basically ends up calling create standard font menu to do its job. And there are a couple of new APIs that go along with this that I'll talk to you about in a minute.

So here's the Create Standard Font menu call. Basically you get your menu handle. And as Nathan showed in his demo, you have two options. Excuse me. You can create a flat representation of the font or a hierarchical, more compact representation of the font, which basically takes a font family and then appends a submenu with all the criteria styles that are associated with it. So here in the call, it's very simple. In this one, you specify the hierarchical font menu, and it returns to you a hierarchical font menu count cookie that you'll need later.

So, what happens when the user clicks on the font menu? So, if you had just your plain old flat space font menu, you called menu select and get the menu item and the name and then from there go to the font family. A better way to do this, which takes advantage of some of the features of TEN, is to, before you call menu select, you call update standard font menu.

What this does for you, if you created the font using the create API that I just showed you, is that it will keep track of the generation for you. So, if you call this call before the menu select, it will find out if the database, the font object database has changed and if so, it will recreate the font menu and Nathan showed that in his demo.

So once you have that, once you call menu select, you get the menu ID and from there you can call get font family from menu selection, which in the flat menu space will just return to you the font family. But in the case of the hierarchical menu, it will also give you the style that the user picked.

Lastly, I want to talk a little bit about performance, some of the issues that you might or might not be aware of as you start developing for Tent. The history here is that we moved to 10. The major issue was that we don't have the single memory space that we had on 9. So font data is quite extensive and we had to come up with a way to share this data across all the ATS clients. So we ended up having a server.

What this means to the client is that some of the APIs you call end up sending messages to the server, whereas before on 9 there was no such thing, it was quite fast. So it is something that you might need to pay attention to if you start to see that some things that were faster, seem faster on 9 and not so on 10. You can start using some of the tools available on 10 such as Stop or Sample to find out what the activity is to the ATS server.

Another area of concern is font file on the OS X. On Mac OS X, every single font file that was available to you was open, basically. On X, we can't afford to do that since every process lives in its own little world, so we manage this. So, through font file iteration, it is possible that you will iterate through every single font file. Say if you wanted to create your standard, sorry, not your standard, but you know, a special font menu, some nifty font menu that we do not provide, and you want to iterate through all the fonts in the system.

Well, this will cost messaging to the server. Along with that, it will cost some of the file caches that we have to get thrashed, which is perfectly fine if we do not provide what you need in the APIs that we have. However, what you need to keep in mind is that you might want to cache this information to avoid this sort of iteration.

Another way is the usage of the APIs we provide. For example, the activation set of APIs allows you to activate a font file or a directory. So, it's far more efficient to activate a directory than if you had some old code that had just activated a file at a time, because that will create multiple messages to the server.

So, one final note is, please use the APIs that we've provided whenever possible and not go to the low level and dig your own data. The reason being is that we have optimized the APIs for messaging to the server, for keeping the files open. Moreover, we have a good set of caches on the server, that makes things easier for us. So, please stick to the APIs whenever you can. Now, I'd like to take a moment and invite Scott Thompson from Macromedia and he'll give us a real-life example of what he had to do to bring up this app under 10, especially to do with font management.

Hope you don't mind my cheat sheet here. Let's see if I can figure out how this magic works. Okay, great. So, my name is Scott Thompson. I'm a senior software alchemist and the Macintosh technical lead for Macromedia Freehand. We just recently shipped Freehand 10. They showed a demo of it in the keynote. I hope you all enjoyed that.

What I want to do is I want to start by telling you a little bit about what Freehand's text needs are, and in particular some of the font things that we have to do. Then I'm going to talk a little bit about the sort of things that we had to do to adopt to the new Font Manager under CarbonLib and Mac OS X.

Freehand 10 as a shipping application is a CFM Carbon application. It uses Quick Draw to do its drawing, despite what you may have seen in some of the reviews of Freehand. We don't do Quartz yet. We began carbonizing Freehand in July of the year 2000 in earnest. We just finished shipping in May.

So, just to give you an idea of how long it went. When we decided to implement the Carbon feature, we implemented it as a feature, we set out a big schedule at the very beginning. We knew that two areas that we were going to have to do a lot of work on were fonts and printing.

So, we put those at the very beginning of the schedule, thinking that if they ran long, we could kind of hop out. Since printing depended on fonts, it turns out that font manager support turned out to be item number one on our Carbon schedule. Having gone through it, fonts was also the biggest thing that we did. It is a very important thing. It consumed the most of my time anyway. Part of that was because it was very complicated. Freehand's usage of fonts was very complicated.

Part of that was because I know a lot more about fonts now than I did when I began. What we see on this slide is a little bit about the text handling capabilities of Freehand, just to give you an idea of what we have. I call it a mid-range text handling capabilities.

We don't do any real super-duper advanced typography. But we do a little bit more than your average text editor. We do multi-column text. We do justification of text, fill, justifying, left, justifying, all that good stuff. We allow the user to do custom kerning and tracking of the text.

We do text on a path, text in a path, text flowing around a path, meaning that you have an object in there and the text goes on the outside of it. And we do postscript output. So where do we begin? Well, the first thing that I started with was the font menu.

Our font menu was being created by, uh, append res menu and all that good stuff. One of our big goals for Freehand was to sort of get away from the idea that all fonts had to have a resource fork, in particular a font, because, you know, one of the really nice features that you can do on Mac OS X that a lot of our customers are really excited about is you grab your Windows font, drag it over to the Mac OS X machine, drop it in there, it shows up, it works, it's really great. So a lot of our code was geared at understanding that fonts always had a font, always had resources, and we had to get away from that.

Um, so in that vein, the first thing we did was create the font menu. It was being done through append res menu. Uh, we had to change that to use create standard font menu. Uh, we ran into one little interesting thing. In that Freehand is a quick draw application, uh, when we created the hierarchical menu, using the hierarchical option, uh, we found out that it was adding a lot of fonts that are available to at SUI, but are not necessarily available through QuickTime.

So that's something you want to keep in mind. If you want to have the hierarchical menu inside your quick draw application, you can do it, but you're going to have to do it in a different way. So, we're going to do that. But you're going to have to use the font iterators to, uh, to create your own menu and all the other good stuff.

Um, Oh my dear, what did I write? So in the vein of getting rid of fonts or getting our reliance on fonts done, we had one interesting challenge and the biggest challenge turned out being that we wanted Freehand 10 to continue to support Mac OS 8.6. Mac OS 8.6 doesn't have all the nice font manager routines that you have under Mac OS 9 and Mac OS X.

So we had to do a little bit of abstraction, a little bit of keeping the old code around so they could still parse the fonts and that sort of thing. In the end, it turned out that that wasn't such a bad idea because we found some pitfalls along the way with using the font manager routines where there were differences between the information that we got back from the font manager routines and the information that you would pull out of the fonts.

Some of those things have been taken care of because we reported them as bugs and the Apple engineers fixed them for us. So hopefully, you'll never have to see those sorts of things. So this slide talks a little bit about the kinds of things that we used to get out of the font. We used to get font names. In particular, we were interested in the PostScript font name because Freehand downloads PostScript to the printer. We deal a lot with PostScript names.

In terms of saving our font IDs, that's what we save usually is the PostScript font name. We would get glyph widths and other glyph metrics. Some of those things, I had no idea what they were but by golly, I learned. We had to get the glyph re-encoding tables.

If you're downloading fonts to the printer, you have to know how the fonts can be re-encoded, the Mac encodings and all that other good stuff. We got things like kerning pair information and other such things. We were able to find substitutes for all of these things in the new font manager APIs.

For 8.6, of course, we just continued using fonts and didn't have a problem. Under Mac OS 9, we tended to lean more towards the FM Font Manager, the calls that begin with FM, and we used some of the ATSU font manager routines. And then on Mac OS X, there are actually two cases where you had to drop to the ATS framework, load the framework out from the system. One of those was ATS Find Font Family Resource.

You'll have to ask Julio later whether you should use ATS Find Font Family Resource or whether you should actually go through the thing that he had on the slide. We're probably doing the wrong thing. And then we also had another routine that called ATS Activate Font. Freehand has two fonts that it stores in its resource fork and we had to activate those fonts so we had to load that out of the Carbon bundle, or out of the bundle using CFBundle.

For the Postscript names, the routines that we found particularly helpful was ATSU Find Font Name and ATSU Find Font Name. The ATSU routines give you a lot of information about how to get names out of the font tables and they're really handy for finding a lot of information.

For example, I didn't know that fonts can actually contain localized font names, but you can get those using ATSU Find Font Name. I want to warn you a little bit about the routine ATSU Find Font From Name. We used ATSU Find Font From Name initially in our first pass to find fonts based on their postscript name all the time. That turned out to be a little bit of a mistake because that routine doesn't perform really well on Mac OS 9.

I'm led to understand that the caching schemes on Mac OS 9 and Mac OS X are very different and so as a result it performs fine on Mac OS X, but under Mac OS 9 you can get poor performance out of the routine. What we ended up doing was continuing to rely on the font information, trying to find the font by parsing the font first, and if that doesn't work then we go to ATSU Find Font From Name. That worked out really well.

Glyph widths and other glyph metrics, I found replacements for those in a lot of the updated Quick Draw font measuring routines. Sounds really odd. You have to remember freehand is a really old application. A lot of the stuff that we did during our carbonization was actually modernization, bring us up to the new brave new world. And so we were relying on some stuff from the font that could actually be gotten from Quick Draw routines from then on.

Glyph re-encoding tables, I believe we get those from the font as well. If there's not a font, then we just let the printer driver handle it and go on with our lives. Currenting pair information also, I believe, comes from the font and if the font's not there, we just skip it.

The other big change that we made in Freehand was finding glyph outlines. In Freehand you can take a bunch of text, convert it to paths, get the outlines of the fonts, and then do special effects on them. These are the four ways that Freehand 10 can actually use to get font outlines.

We have our own PostScript Type 1 font parser that's inside of Freehand. We have our own TrueType font parser. We also talked to the Adobe Type Manager backend. For those of you that are going through Adobe Type Manager, I don't know if Adobe's actually released sort of a carbonized glue code for their Adobe Type Manager, but I was able to load some routines from Interface Live and actually continue to use the Adobe Type Manager backend online. And now we use the Atsui low-level programming interface. The Atsui stuff is actually really, really nice. It's really handy. You pass it off a set of glyphs that you want the outlines for, give it a set of callbacks. It comes back. and iterates two things.

In closing, I'd like to talk about one pitfall that I ran into that you'll probably want to start thinking about. Number one, you'll notice that a lot of the higher-end text formatting options that Freehand has can now be handled by Atsui. So if you have the choice between using your own font layout engine or using Atsui, my recommendation would be try and use Atsui first because it's going to save us a whole lot of trouble in the future, I think.

Another one that I would encourage anyone that's writing an application that uses fonts, go ahead and call the folks at Adobe and buy some OpenType fonts and start testing with them now. OpenType fonts don't have resource forks. They have special things. They don't tend to go through TrueType parsers the way you might think because sometimes the found outlines aren't TrueType outlines. They're CFF or PostScript Type 1 outlines. And Freehand was a challenge. It was a lot of fun and I hope that the information I provided has been useful. Okay. Okay? Thank you.

Thank you Scott, that was great. Just to wrap it up in summary, Scott basically summarized it all for us here. As you go on and bring your applications up to 10, the first thing to do is remove as much Resource Manager dependencies as you have in your application.

Please try to remember just like Scott did in his app, not all fonts that are going to be present are going to have a font in there. They're not going to even have a resource fork in them. So try to move as much away from using the Resource Manager to get your data as possible.

And we'll be giving you some help with that in the future also. Then, as far as the API sets that I talked about, the same as Scott did, the FM set of APIs are available to you under 9 and Carbon Live. Whereas the ATS font set of APIs are just available for 10 and it's basically work in progress.

That's where we want to be in the future, but we're not quite there yet. So concentrate on using the FM font set of APIs and we're pretty certain that you can get most of what you need. In some cases, you might have to dip down and go to the ATS font API set, but hopefully that won't have to be too much.

So here are some sessions that have gone on that are related to, somewhat related to font management. There was the text session yesterday. I don't know if all of you were able to attend, but you can find that session on video and you will, especially you will, the references that Scott made to Atsui, the Atsui set of APIs, they were talked about in this session, so you might find that useful.

Coming up, there's the Using Cocoa session, and you can learn how text and fonts are handled by Cocoa. And later today on at 5, there's the International Feedback Forum, in which you can also ask us some questions that you might have, that we might not have time to answer here later on.

So here's some pointers for you regarding documentation. There is, up on the website right now, the Font Manager technical documentation that you see there. It covers the FM font set of APIs, the Extended Quick Draw Text Font Manager APIs. However, there is no documentation to the ATS font set of APIs at the moment. Again, it's a work in progress and as soon as we complete it, there will be some documentation that goes along with it.

If you're interested in storing pretty good font references in your documents, I recommend that you read the Font Sync technical documentation that is also there on the website. Finally, I want to make mention of something that is not on this slide, which is there's a tech note that we're working on and we've got almost complete, which covers most of what I've talked about here today, but in far more detail. So please look for it on the website where all the technical notes are issued. be forthcoming. I don't expect it to be much longer.

Finally, if something comes up tomorrow, day after tomorrow, and you need to talk to us about a feature that you want added, some problem that you have, some issue that we haven't addressed properly in our APIs, please feel free to contact Xavier Legro, who is the Worldwide Developer Relations contact for our group. he's got our ear pretty much to his He acts pretty good and we do pay attention to him. He gives us a lot of good feedback.