The 'Zapf' Table

General table information

One of the assumptions underlying modern layout engines is that characters and glyphs are different. The mapping of character to glyph and the subsequent processing of glyphs are clearly separated steps. This separation permits tremendous flexibility in how fonts are laid out, and removes us from the old straitjacket of fixed glyph repertoires per script. It means the font's 'cmap' table doesn't need to cover every glyph in the font.

However, because of this separation, as well as the intensive processing which happens to the glyphs themselves during layout, it's difficult at best to deduce which characters were originally associated with the final resulting glyphs in a layout. For instance, while Adobe Acrobat now provides users with the ability to search PDFs for content strings, this capability is difficult to implement for embedded TrueType fonts, since the streams were captured as just bunches of glyphs. The original strings aren't there any more to be searched.

What we need for a given font is a collection of information, per glyph, which can be used to associate semantic information with that glyph. For a given glyph, we'd like to be able to answer these questions:

• What Unicode code point(s) are associated with this glyph? This might involve Unicode combining or other special characters, as well as the raw Unicode characters themselves (which might be simple 16-bit Unicodes, or surrogate pairs of 16-bit values). Note that this question really involves the sequence of Unicodes which, when combined with layout processing, results in the given glyph. The fact that Latin 'A', Cyrillic 'A' and Greek 'A' have different Unicodes but are potentially the same glyph is not addressed by the 'Zapf' table. Outside mapping tables could provide this kind of information.
• When typing in an advanced layout application, what features need to be specified in order to get this glyph? That is, what combination of character codes, context, feature types and selectors, etc. is needed to have this glyph appear?
• What other glyphs in the font (if any) could be grouped with this one as appearance variants? That is, if an application wished to present a palette of glyphs which are all variations of the same character (or ligature), which glyph indices would it need to use to build that palette?
• What are the names for this glyph? Currently there is a single name in the 'post' table, but numerous problems with standardization have caused most type designers to simply give up and use format 3 'post' tables, which have no names at all! It would be helpful to have a single place to store the Adobe standard name, the Apple name (if different), the AFII designation for this glyph, CID indices, and any other means of identifying the glyph with some known meaning or semantic. (Note that these names are not intended for display by an application which chooses to use them; they're not localizable, for instance. They should be thought of as symbols, and not strings)
• What are the strings the designer might wish to associate with this glyph? In order to assist users of a font, a designer might wish to include helpful hints about the usage of a particular glyph, or even a brief historical note (perhaps for pedagogical purposes). Since these strings will be displayed to a user, they need to be localizable, and thus in the 'name' table.

By collecting all this information into one placeÑthe 'Zapf' table—named with permission after legendary type designer Hermann Zapf—can make it much easier for the user interface parts of applications to get what they need to present sensible choices to their users. This document proposes a format for this table which represents all this information in a relatively compact form.

Table Format

Header

The 'Zapf' table has the following header:

The GlyphInfo structure

The header is followed immediately by an array of GlyphInfo structures. Each entry in this array is of variable size; the offset to a particular GlyphInfo is contained in the offsets[] array in the header. A GlyphInfo structure has the following format:

The KindName structure

A KindName identifies a name for this glyph, and what kind of name it is. In order to accommodate the need for both machine-readable names (for font tools) and human-readable names (for constructing font UI), the KindName's kind byte has its top two bits interpreted differently from its bottom six bits. This has the effect of dividing KindNames into three groups, as follows:

The format of a KindName is as follows:

The Unicode KindName should only be used for glyphs corresponding to a single Unicode character. Ordinarily, such names can be inferred entirely from the Unicode Standard. This name might be useful, however, for a designer creating an experimental font for an unencoded script used in the Unicode Private Use Area.

The GroupInfo and GroupInfoGroup structures

When presenting an interface to a user for the selection of particular glyphs, an application would often like to know the set of glyphs in a font which are logically related (or perhaps, those which are related in the designer's eye). In order to accommodate this, the GroupInfo structure gathers together information about related glyphs. A GroupInfo is a collection of NamedGroup structures, where each named group has a name (via a 'name' table index), and a collection of glyph indices in whatever order the designer sees fit to impose. So for instance, a designer whose font contains many different swashes for a given letter could create groups for all the glyphs for that letter, where each group has a name (e.g. "long-tailed," "fat-stemmed," etc.)

The NamedGroup structure

NamedGroup structures reside in the extraInfo space, and have the following format:

Now that we have described the NamedGroup, we can describe the GroupInfo and GroupInfoGroup proper.

The GroupInfoGroup structure is to be used for glyphs contained in more than one group. It looks like this:

The GroupInfo structure looks like this:

A key part of the GroupInfo is the nGroups field, which counts the number of groups being defined. This is a 14-bit unsigned constant; the top two bits indicates whether flag information is associated with each group or whether a series of 32-bit offsets to groups is found instead of a series of NamedGroups. If these bits are off, then each group is just a NamedGroup inline, seriatim. If the top bit is on, then each group is preceded by a 16-bit flags word, whose flags indicate the following:

Let's look at a few examples to see how this structure can be used to represent various glyph groupings. First, in the simplest case, the font designer wishes to include ten different swash ampersands in a font, and wishes to group them together so the user can choose one. In this example, each ampersand glyph's GlyphInfo structure will have the same groupOffset value, an offset which will refer to the following GroupInfo:

An application could use this information to present the user with a simple palette of the ten ampersands to choose from.

In a slightly more complex example, the designer still has ten swash ampersands and wishes the user to see all ten of them, but grouped into labelled groups, with an overall label, so that a menu would look something like this:

All ten ampersands' GlyphInfo structures would still have an offset to the same GroupInfo, which now would look like this:

A yet more complex example deals with a font designer who wishes to have glyphs belong to multiple groups. For example, the ten ampersands of our previous example are to have all the characteristics just described, but they are also to belong to a separate group of all punctuation in the font. Again, each ampersand could have the same groupOffset value, referring to this GroupInfoGroup structure:

The period glyph would also be a member of the punctuation group, but (unlike the ampersand), it has no alternate glyphs for the user to select. Its GlyphInfo structure would contain an offset to a GroupInfoGroup like this:

The punctuation GroupInfo would look like this:

The FeatureInfo structure

A FeatureInfo structure identifies the layout engine inputs which force the appearance of this glyph. In many cases, nothing is specified because the given glyph is the default glyph for the specified Unicode(s). An example of this is 'A', where nothing else needs to happen. However, in the case of multiple swashes, line-start or line-end swashes, or contextual forms, more information is needed to let the user know how to get this glyph when a line is being laid out. (Of course, an application could just present the user with a palette of all the glyphs in the font, but that can be overwhelming sometimes!)

One of the interesting problems here is the identification of kinds of context which matter in the choice of certain glyphs. The list below is Apple's first attempt at listing these; no doubt we've missed some. We welcome other suggestions!

The format of a FeatureInfo is as follows:

Example

To help clarify how all this information is represented, let's look at a concrete example. Suppose we have a font with this (somewhat odd) repertoire:

The numbers are the glyph indices, and the images show the actual glyphs. Here is an example 'Zapf' file for this font:

Mac OS-specific information

The contents of the 'Zapf' table not used directly by the system; they are made available to application programmers through the Carbon Font Manager APIs.

Newton-specific information

The 'Zapf' table is not used by the Newton OS.

Dependencies

The 'Zapf' table contains a table with an entry for every glyphs; this must be updated whenever the glyph count recorded in the 'maxp' table changes.

Tools

Hex editing of the 'Zapf' table is possible using TrueEdit. Conversion of 'Zapf' table data to and from text files is possible through DumperFuser.

Change Log

14 September 2000

Initial public version.

[Table of Contents]