glyf | Chrome new tab extension | Browser Plugin library

It looks like Chrome, which uses OTS, doesn't support format 0.

In general, you might find the current OpenType specification helpful as it contains a number of updates, clarifications, and corrections that don't appear in the Apple version.

As to your specific questions:

1 head.checksumAdj calculation

The instructions are reasonably clear, though there is an implied "step zero" of assemble all font data (tables, directory, etc.) into final form and order. Once you have that:

1. set the value of checkSumAdj in the head table to zero

2. calculate the checksum of just the head table and store it in the corresponding field in the font's table directory (where tag/checksum/offset/length are stored for all tables included in the font)

3. calculate the sum of the entire font (sum of all uint32s, just like table checksums), including the modifications in steps 1 and 2.

4. store 0xB1B0AFBA minus the value from step 3 in head.checkSumAdj. That's all! The wording about the head checksum appearing incorrect means that if you were to run the checksum calculation on the head table after storing the final value, it would appear wrong. But that is okay, because that's how it was defined: essentially for the checksum of the head table, you must ignore (set to 0) the checkSumAdj value first.

2 head xMin, xMax, yMin, yMax

This is simply the xMin, xMax, yMin, and yMax of all glyphs. Each glyph xMin, xMax, etc. is quite simply "the minimum (maximum) X (Y) coordinate" of all points (for compound glyphs, you would take that result after composing the glyph, i.e. after applying any shift, scale, or other transformations in the composite glyph definition). In both the head table and glyph data, the bounding box is an array of 16-bit signed integers. So generally the procedure would be to loop over every glyph, get the calculated bounding box, and as you are doing this, keep track of the X/Y min/max (independently). When you are done with the loop, you'll have the values for the head table which is essentially a rectangle that includes every coordinate of every glyph in the font.

3 maxp values

These are reasonably well-defined in the maxp table definition:

• maxPoints is the maximum number of points of any single non-composite ("simple") glyph

• maxContours is similarly the maximum number of contours of any single non-composite glyph

• maxComponentPoints is the maximum number of points in a composite glyph (i.e. the sum of points of all component glyphs)

• maxComponentContours is similarly the maximum number of contours in a composite glyph

• maxTwilightPoints refers to the maximum number of "twilight" points used in Zone 0 of TrueType instructions. If your font does not make use of TrueType instructions, this (and other instruction-related fields) can be set to zero. You might want to review the "Instructing TrueType Glyphs" and "TrueType Instruction Set" sections of the OpenType specification if you are not familiar with TrueType instructions (often referred to as "hints") and how they are stored in the glyph data.

4 glyf table simple glyph flags

uint8 flags[variable] indicates that the length of the flags array is variable. The reason for that is discussed in the specification ("Simple Glyph Flags"):

In logical terms, there is one flag byte element, one x-coordinate, and one y-coordinate for each point. Note, however, that the flag byte elements and coordinate arrays used packed representations. In particular if a logical sequence of flag elements or sequence of x- or y- coordinates is repeated, then the actual flag byte element or coordinate value can be given in a single entry, with special flags used to indicate that this value is repeated for subsequent logical entries.

In other words, the elements of the flags array, when expanded are per-coordinate, but the actual storage as an array of uint8 is not necessarily (as with the storage of the coordinate data itself). It largely depends on the arrangement of coordinates in each glyph.

I found that in the standard Arial font there are four compound glyphs that have another compound glyph as a component. One example is the glyph at index 471, which is used for unicode U+01FB (latin small letter a with ring above and acute). It consists of the Acute glyph, which is a simple glyph, and the small latin a with ring above, which is a compound glyph.

Composition of glyph 471 in TrueType font Arial:

So the conclusions from this are:

1. Recursivly compound glyphs are possible in TrueType/OpenType fonts.
2. These glyphs exist in common fonts.

What is a "point number"? Is it an index into the glyph's points?

Yes. It’s an index into the array of pairs of coordinates that make up the glyph’s outline (as defined in the glyph’s contour data).

What does "matched to the new glyph" mean?

It means that the new component glyph of that composite/compound glyph is to be positioned so that the coordinates of its ‘match point’ are equal to those of the ‘match point’ of the base component glyph. In other words: so that the indicated points for the two components match. This is repeated for each new component glyph, with the point numbers/indices of the already matched components being treated as if it were a single, base component glyph.