Important: QuickDraw is deprecated in Mac OS X version 10.5 and later. Use Core Text instead for Mac OS X v10.5 and later, as described in Core Text Programming Guide. For applications that must run on Mac OS X v10.4 and earlier, use Apple Type Services (ATS), as described in Apple Type Services for Fonts Programming Guide.
Prior to the release of Mac OS 8.5, the Font Manager supported only bitmapped fonts and TrueType outline fonts whose data were stored only in the resource fork. With the release of Mac OS 8.5, Apple began to provide support for TrueType and OpenType fonts that are stored in data–fork files. As a result, you can use the Font Manager to access both resource–fork and data–fork fonts. There are many new Font Manager functions you can use to assure your application supports both kinds of fonts.
Data–Fork Fonts
Resource–Fork Fonts
Font File Formats
Font Family and Font References
Compatibility Issues
There are currently two types of data–fork fonts: TrueType and OpenType. TrueType data–fork fonts originated on the Windows platform. These fonts store data in an 'sfnt' structure in a file with the extension .TTF. In the past, to use these fonts in the Mac OS, a user would first have to use a utility to convert the font as a resource-based suitcase. Starting with Mac OS 8.5, this is no longer necessary.
TrueType collections, or .TTC files, contain several 'sfnt' font structures organized with a simple directory scheme. This organization allows the individual fonts to share complete tables among each other. Until now, these fonts have also not been usable on the Macintosh. TrueType collections have the file type 'ttcf'.
OpenType represents new naming and packaging for fonts. Adobe, in conjunction with Microsoft, have defined a data–fork-based, 'sfnt' structured font file to contain PostScript font data. The 'sfnt' structure is in a file with the extension .OTF. The glyph data itself is stored in a new format called CFF, or Compact Font Format. The structure was designed such that these fonts behave the same as TrueType fonts on the Windows platform. These fonts are also designed to work in the Mac OS.
An OpenType font file contains data, in table format, that comprises either a TrueType or a PostScript outline font. Rasterizers use combinations of data from the tables contained in the font to render the TrueType or PostScript glyph outlines. Some of this supporting data is used no matter which outline format is used; some of the supporting data is specific to either TrueType or PostScript.
The Finder in Mac OS 8.5 was enhanced to support identification and autorouting of data–fork font files. Individual font files (.TTF and .OTF) and collection files (.TTC). are assigned file types 'sfnt' and 'ttcf', respectively, by Internet Config when the fonts are first brought onto the system. When dropped into the System Folder, the Finder assigns appropriate icons to the files and automatically routes them to the Fonts folder.
Currently, there is no support for double-clicking a data–fork font file. They behave most like the individual TrueType files (as opposed to suitcases) and as such, they cannot be renamed or opened.
The Font Manager takes care of the details of how fonts are stored in resources, reading the resource fields when required and building internal representations of the data stored in them.
There are three types of resources associated with resource–fork fonts:
Bitmapped font ('NFNT') resources describe bitmapped fonts. These bitmapped font resources have an identical structure to the earlier 'FONT' resources, which they replace, but the bitmapped font resources add a more flexible numbering scheme.
Font family ('FOND') resources describe font families, including information such as which fonts are included in the family and the recommended width for a glyph at a given point size.
Note: 'FONT' resources that are not referenced by a 'FOND' resource are not supported. 'FONT' resources are not supported in Mac OS X and should be converted to 'NFNT' resources.
There are a variety of font file formats you should be aware of when working with the Font Manager. The font file formats can have different implications for how the fonts are enumerated and font data is accessed in Mac OS X versus in Mac OS 8 and 9. The most important file formats include the following:
Suitcase. There are resource–fork and data–fork suitcases. If you want to use a suitcase in Mac OS 9, you should package it as a traditional resource–fork suitcase. Data–fork suitcases (.dfont) are supported only in Mac OS X.
Multiple-file resource-based PostScript fonts. Outline data is stored in a separate file from the font suitcase. Mac OS 8 and 9 supports plain and Multiple Master LWFN-class fonts. (CID fonts not packaged in an 'sfnt' structure, that is, “naked” CID and OCF are not currently supported in Mac OS X.)
Data–fork fonts. These are fonts that consist of a single data–fork file that contains 'sfnt' font data structures. Typically, there is only one 'sfnt' per file, as with OpenType and Windows TrueType fonts, but there may be more, in which case you would have a TrueType collection file. There is no suitcase associated with the font, so there is no 'FOND' resource or associated bitmapped fonts. This means that in Mac OS 9 (with or without CarbonLib) these fonts do not belong to any font family and cannot be used with the Font Manger and QuickDraw. (See “Compatibility Issues” for information on associating a FOND resource with a data–fork font.) In Mac OS X, the system synthesizes font family information to allow the fonts to be accessible to the entire system.
The font family ID and font ID have been replaced by the font family reference and font reference.
A font family reference (FMFontFamily) represents a collection of fonts with the same design characteristics. It replaces the standard QuickDraw font identifier and may be used with all QuickDraw functions, including GetFontName and TextFont. A font family reference does not imply a particular script system, nor is the character encoding of a font family determined by an arithmetic mapping of its value.
Note: The Font Manager uses opaque data types to store information about fonts and font families. You cannot access a font family or font object directly. Instead, you must use the accessor functions provided in the Font Manager API.
A font family is a collection of fonts, each of which is identified by a font reference (FMFont) that maps to a single font object registered with the font database.
Each font object maps to one or more combinations of a font family reference and a standard QuickDraw style. This is roughly equivalent to the information stored in the font association table of the 'FOND' resource handle, with the exception of a descriptor for point size. Since each font object represents the entire array of point sizes for a given font, a font family reference and style together fully specify any given font object. A font family instance (FMFontFamilyInstance) is a data structure that contains a font family reference, font style, and font size.
The system software always maps the system font to sysFont and the application font to applFont. The system software uses the system font for drawing items such as system menus and system dialogs. The application font is the font that your application uses for text unless specified otherwise by you or the user. The fonts assigned as the system and application fonts depend on the Appearance Manager settings as well as the Script Manager variables smScriptSysFond, smScriptAppFond, smScriptSysFondSize, and smScriptAppFondSize.
You should read this section only if you need to parse a font association table for a 'FOND'resource.
The Font Manager cannot make use of any font for which there is no 'FOND' resource, as that resource forms the basis for accessing and processing fonts. Data–fork fonts do not have a 'FOND' resource and so are not usable as is by the Font Manager in Mac OS 8 and 9 or the Classic environment, but they are usable in Mac OS X. It is not possible right now for the Font Manager to synthesize a 'FOND' resource, but there is a work-around the Font Manager uses to connect a 'FOND' resource to a data fork. It involves the creation of an 'afnt', or font alias, resource.
The Font Manager uses the 'FOND' font association table to choose from among the available bitmap sizes in a font, or to elect to use an outline font. Each entry in the font association table contains a size field to indicate the bitmap size, with the special value of zero denoting an outline font ('sfnt' resource). The Font Manager uses the entry's resource ID to access the appropriate type of resource using the Resource Manager.
Starting with Mac OS 8.5, Apple defined the size (-1) to indicate that an outline font is stored in a data fork. The font association table entry’s resource ID is 'afnt'. An 'afnt'resource is simply an alias record that has the structure shown in “Figure 2-10.” For more information on alias records, see the Alias Manager Reference in Carbon File Management Documentation.
Apple currently reserves all of the user bits and has defined the least significant:
A value of all zeros for the user bits indicates a simple, single–font data fork. The alias data can be passed to the Alias Manager for resolution. The target font is then expected to begin at offset zero in the file.
If the least significant byte of the user bit word is 1, then an offset into the data–fork file is present following the private alias data in the resource. This is used for targeting a member of a TrueType collection file. Thus, an 'afnt' resource targets a single font.
Starting with Mac OS 9, a font management utility can activate data for fonts by simply making a 'FOND' and associated 'afnt' resources visible to the Font Manager. The data for files themselves can reside outside the Fonts folder. When creating the alias that goes in the 'afnt' resource, do not make a “minimal” alias. Ideally, the alias should be relative to the temporary file (or the suitcase file, if a suitcase is created). Keeping the data–fork file out of the Fonts folder is efficient since the system opens the data–fork file only when needed. Although you can reference data forks on network volumes, it is not recommended because the network connection could close unexpectedly in midstream. Data–fork files can also be stored on and accessed from CDs.
Last updated: 2007-12-11