(cache) The Compact Font Format Version 2 Table

Microsoft Typography | Developer... | OpenType specification | OpenType tables | The CFF2 table

CFF 2 – Compact Font Format (CFF) Version 2

Contents

1 Introduction

This document describes the CFF 2 format. Like the CFF 1.0 format, CFF 2 allows efficient storage of glyph outlines and metadata. The CFF 2 format differs from CFF version 1.0 in that it cannot be used as a stand-alone font program: it is intended for use only in the context of an OpenType font as an 'sfnt' table with the tag CFF2, and depends on data in other OpenType tables. All the data from the 1.0 format that is duplicated by data in other tables, or which is not used in the context of an OpenType font, is removed.

Another important difference is that the CFF 2 format adds new operators which allows CFF 2 to represent the data for a variable font: a font which includes several different versions of each glyph, which can be blended to produce an intermediate instance. See the chapter, OpenType Font Variations Overview, for a general overview of OpenType Font Variations and for a complete list of the tables required to support a variable font.

Finally, the CFF 2 format requires the use of CFF 2 Charstrings rather than Type 2 CharStrings. This CharString format, like the CFF 2 format itself, has removed operators to reduce file size, and added new operators to support Font Variations. See section 9 for additional information on CFF 2 Charstrings.

For a complete description of the differences between CFF format version 1.0 and CFF 2, see Appendix D. Changes From CFF 1.0.

2. Data Layout

Conceptually, the binary data is organized as a number of separate data structures. The overall layout within the binary data is shown in Table 1. The first three structures occupy fixed locations. The remainder are reached via offsets, and their ordering can be changed.

Table 1 CFF Data Layout 

Entry Comments
Header –
Top DICT –
Global Subr INDEX –
Variation Store –
FDSelect –
FDArray INDEX –
Private DICT –
per FDArray Font DICT –
CharStrings INDEX –

Appendix A. Example CFF 2 Font shows an annotated example of a CFF2 table.

3. Data Types

This section describes data representation and types used by the format.

All multi-byte numeric data and offset fields are stored in big-endian byte order (high byte low offset) and do not honor any alignment restrictions. This leads to a format that is free from padding bytes.

Data objects are often specified by byte offsets that are relative to some reference point within the CFF data. These offsets are 1 to 4 bytes in length. This document uses the convention of enclosing the reference point in parentheses and uses a reference point of (0) to indicate an offset relative to the start of the CFF data and (self) to indicate an offset relative to the data structure containing the offset.

The CFF format data types are shown in Table 2.

Table 2 CFF Data Types

Name Range Description
Card8 0 – 255 1-byte unsigned number
Card16 0 – 65535 2-byte unsigned number
Offset varies 1, 2, 3, or 4 byte offsets (specified by OffSize field in an Index table)
OffSize 1 – 4 1-byte unsigned number specifies the size of an Offset field or fields

This document describes data structures by listing field types, names, and descriptions. Data structures may be given a type name and subsequently described. Arrays of objects are indicated by the usual square bracket convention enclosing the array length.

The majority of CFF data is contained by either of two data structures called DICT and INDEX which are described in subsequent sections.

4. DICT Data

Font dictionary data comprising key-value pairs is represented in a compact tokenized format that is similar to that used to represent Type 1 CharStrings. Dictionary keys are encoded as 1- or 2-byte operators and dictionary values are encoded as variable-size numeric operands that represent either integer or real values. An operator is preceded by the operand(s) that specify its value. A DICT is simply a sequence of operand(s)/operator bytes concatenated together.

A number of integer operand types of varying sizes are defined and are encoded as shown in Table 3 (first byte of operand is b0, second is b1, and so on).

Table 3 Operand Encoding

Size b0 range Value range Value calculation
1 32 – 246 –107 – +107 b0–139
2 247 – 250 +108 – +1131 (b0–247)*256+b1+108
2 251 – 254 -1131 – -108 –(b0–251)*256–b1–108
3 28 -32768 – +32767 b1<<8|b2
5 29 –(2^31) – +(2^31–1) b1<<24|b2<<16|b3<<8|b4

Note: The 1- , 2-, and 3- byte integer formats are identical to those used by Type 2 CharStrings.

Examples of the integer formats are shown in Table 4.

Table 4 Integer Format Examples 

Value Encoding
0 8b
100 ef
-100 27
1000 fa 7c
10000 1c 27 10
-10000 1c d8 f0
100000 1d 00 01 86 a0
-100000 1d ff fe 79 60

A real number operand is provided in addition to integer operands. This operand begins with a byte value of 30 followed by a variable-length sequence of bytes. Each byte is composed of two 4-bit nibbles as defined in Table 5. The first nibble of a pair is stored in the most significant 4 bits of a byte and the second nibble of a pair is stored in the least significant 4 bits of a byte.

Table 5 Nibble Definitions  

Nibble Represents
0 – 9 0 – 9
a . (decimal point)
b E
c E–
d <reserved>
e – (minus)
f end of number

A real number is terminated by one (or two) 0xf nibbles so that it is always padded to a full byte. Thus, the value –2.25 is encoded by the byte sequence (1e e2 a2 5f) and the value 0.140541E–3 by the sequence (1e 0a 14 05 41 c3 ff).

Operators and operands may be distinguished by inspection of their first byte: 0–21 specify operators and 28, 29, 30, and 32–254 specify operands (numbers). Byte values 22–27, 31, and 255 are reserved. An operator may be preceded by up to a maximum of 48 operands.

An operator may have one or more operands of the types shown in Table 6.

Table 6 Operand Types

Type Description
number Integer or real number
boolean Integer type with the values 0 (false) and 1 (true)
array One or more numbers
delta A number or a delta-encoded array of numbers (see below)

The length of array or delta types is determined by counting the operands preceding the operator. The second and subsequent numbers in a delta are encoded as the difference between successive values. For example, an array a0, a1, ..., an would be encoded as: a0 (a1–a0) (a2–a1) ..., (an–a(n–1)).

Two-byte operators have an initial escape byte of 12.

Further compaction of dictionary data is achieved by establishing default values for various DICT keys. For those keys that have a default value the absence of the corresponding operator in a DICT implies a key should take its default value.

(A list of DICT operators for the Top and Private DICTs may be found in section 8 and section 12, respectively.)

5. INDEX Data

An INDEX is an array of variable-sized objects. It comprises a header, an offset array, and object data. The offset array specifies offsets within the object data. An object is retrieved by indexing the offset array and fetching the object at the specified offset. The object’s length can be determined by subtracting its offset from the next offset in the offset array. An additional offset is added at the end of the offset array so the length of the last object may be determined. The INDEX format is shown in Table 7.

Table 7 INDEX Format

Type Name Description
Card32 count Number of objects stored in INDEX
OffSize offSize Offset array element size
Offset offset [count+1] Offset array (from byte preceding object data)
Card8 data [<varies>] Object data

Offsets in the offset array are relative to the byte that precedes the object data. Therefore the first element of the offset array is always 1. (This ensures that every object has a corresponding offset which is always nonzero and permits the efficient implementation of dynamic object loading.)

An empty INDEX is represented by a count field with a 0 value and no additional fields. Thus, the total size of an empty INDEX is 2 bytes.

Note 2: An INDEX may be skipped by jumping to the offset specified by the last element of the offset array.

6. Header

The binary data begins with a header having the format shown in Table 8.

Table 8 Header Format

Type Name Description
Card8 major Format major version. Set to 2.
Card8 minor Format minor version. Set to zero.
Card8 hdrSize Header size (bytes)
Card16 topDictLength Length of Top DICT structure in bytes.

The hdrSize field must be used when locating the start of the Top DICT data. It is provided so that future versions of the format may introduce additional data between the topDictLength field and the Top DICT data in a manner that is compatible with older implementations.

7. Top DICT Data

This is the top-level FontDICT of the CFF2 table, corresponding to the top-level dictionary of a PostScript font.

The names of the Top DICT operators shown in Table 9 are, where possible, the same as the corresponding Type 1 dict key. Operators that have no corresponding Type 1 dict key are noted in the table below along with a default value, if any. (Several operators have been derived from FontInfo dict keys but have been grouped together with the Top DICT operators for simplicity. The keys from the FontInfo dict are indicated in the “Default, notes” column of Table 9.)

Table 9 Top DICT Operator Entries 

Name Value Operand(s) Default, notes
FontMatrix 12 7 array 0.001 0 0 0.001 0 0
CharStrings 17 number –, CharStrings offset (0)
FDArray 12 36 number –, Font DICT (FD) INDEX offset (0)
FDSelect 12 37 number –, FDSelect structure offset (0)
vstore 24 number –, Variation Store structure offset.
maxstack 25 number 193, maximum argument stack for all CFF 2 dict and CFF 2 CharString operators.

The FontMatrix operator may be omitted; if it is omitted, the default value is assumed.

The FDArray operator and the structure it points to are required.

The FDSelect operator and the structure it points to are required if the FDArray contains more than one Font DICT, else it must be omitted.

The vstore operator and the structure it points to are required if variation data is present, and must bot be present if there is no varation data.

8. Glyph Organization

A glyph is accessed by glyph ID (GID), which is the index of the glyph in the CharString INDEX. However, it can be useful to have a tag for the glyph which has some semantic content. These are useful for debugging, and can be used as a last resort for deriving encoding information, in some workflows.

For CFF2 tables, the glyph tags can be taken from the 'post' table. The presence of glyph tags is optional. Glyph tags for CFF2 tables are represented PostScript glyph names, using 'post' table version 2.0. In order to omit glyph tags, the CFF2 table should be accompanied by a 'post' table version 3.0.

9. CharStrings INDEX

This contains the CharStrings of all the glyphs in a font stored in an INDEX structure. CharString objects contained within this INDEX are accessed by GID. The first CharString (GID 0) must be the .notdef glyph. The number of glyphs available in a font may be determined from the count field in the INDEX.

The format of the CharString data for CFF 2 data, and therefore the method of interpretation, is the CFF 2 CharString format. This is based on the Type 2 CharString format, and differs only in that some operators are added, and many are removed. See the chapter, The CFF 2 CharString Format for details. The major changes are as follows:

10. Local/Global Subrs INDEXes

A subr is typically a sequence of CharString bytes representing a sub-program that occurs in more than one place in a font’s CharString data. This subr may be stored once but referenced many times from within one or more CharStrings by the use of the callsubr operator whose operand is the number of the subr to be called. The subrs are local to a particular font and cannot be shared between fonts. CharStrings also permit global subrs which function in the same way but are called by the callgsubr operator and may be shared across Font DICTS.

Local subrs are stored in an INDEX structure which is located via the offset operand of the Subrs operator in the Private DICT. A font without local subrs has no Subrs operator in the Private DICT.

Global subrs are stored in an INDEX structure which follows the Top DICT data. A font without any global subrs is represented by an empty Global Subrs INDEX.

Subr numbers are skewed by a number called the “subr number bias” which is calculated from the count of the subroutines in either the local or global subr INDEXes. The bias is calculated as follows: 

    Card16 bias;
    Card16 nSubrs = subrINDEX.count;
    if (CharStringType == 1)
        bias = 0;
    else if (nSubrs < 1240)
        bias = 107; 
    else if (nSubrs < 33900) 
        bias = 1131; 
    else
        bias = 32768;

For correct subr selection the calculated bias must be added to the subr number operand before accessing the appropriate subr INDEX. This technique allows subr numbers to be specified using negative as well as positive numbers thereby fully utilizing the available number ranges and thus saving space. (The above calculation obviates the need for an explicit bias to be stored in the font which is currently the case for Type 1 fonts.) Table 10, Table 11, and Table 12 show the relationship between subr indices, numbers, number sizes and range counts for the different biasing schemes (column headings are described following Table 12).

Table 10 nSubrs < 1240, bias = 107 

Ordered index Reorder index Biased number Size Count
0 - 214 0 - 214 –107 - +107 1 215
215 - 1238 215 - 1238 +108 - +1238 2 1024
Total: 1239

Table 11 nSubrs < 33900, bias = 1131

Ordered index Reorder index Biased number Size Count
0 - 214 1024 - 1238 –107 - +107 1 215
215 - 1238 0 - 1023 –1131 - -108 2 1024
1239 – 2262 1239 – 2262 +108 - +1131 2 1024
2263 - 33898 2263 - 33898 +1132 - +32767 3 31636
Total: 33899

Table 12 nSubrs >= 33900, bias = 32768

Ordered index Reorder index Biased number Size Count
0 - 214 32661 – 32875 –107 - +107 1 251
215 - 1238 31637 – 32660 –1131 - –108 2 1024
1239 - 2262 32876 - 33899 +108 - +1131 2 1024
2263 - 33899 0 - 31636 –32768 - –1132 3 31637
33900 - 65535 33900 - 65535 +1132 - +32767 3 31636
Total: 65536

Where the column headings are interpreted as follows:

  1. Ordered index: subr index ordered by most frequent subr first.
  2. Reorder index: ordered index reordered for bias (this is the index of subrs in the local/global Subr INDEX structures).
  3. Biased number: reorder index with bias subtracted (callsubr/callgsubr operand).
  4. Size: biased number size (bytes).
  5. Count: number of subrs in range.

11. Font DICT Index, Font DICTs and FDSelect.

The Font DICT index contains one or more FontDICT structure. Each Font DICT structure provides at least a reference to a Private DICT structure. A Private DICT provides global hinting data for a set of of the CharStrings.

Table 13 Font DICT Operator Entries

Name Value Operand(s) Default, notes
Private 18 number number –, Private DICT size and offset (0)
FontMatrix 12 7 array 0.001 0 0 0.001 0 0
FontName 12 38 number –, CharStrings offset (0)

If there is only one Font DICT, then all CharStrings reference the one Private DICT. If there is more than one Font DICT, then and only then is the FDSelect structure present. The FDSelect associates an FD (Font DICT) with a glyph by specifying an FD index for that glyph. The FD index is used to access one of the Font DICTs stored in the Font DICT INDEX.

FDSelect data is located via the offset operand to the FDSelect operator in the Top DICT. FDSelect data specifies a format-type identifier byte followed by format-specific data. Three formats are currently defined, as shown in Table 14, Table 15, and Table 17.

Table 14 FDSelect Format 0

Type Name Description
Card8 format =0
Card8 fds [nGlyphs] FD selector array

Each element of the fd array (fds) represents the FD index of the corresponding glyph. This format should be used when the FD indexes are in a fairly random order, and there are no more than 65536 glyphs. The number of glyphs (nGlyphs) is the value of the count field in the CharStrings INDEX. (This format is identical to charset format 0 except that the .notdef glyph is included in this case.)

Table 15 FDSelect Format 3

Type Name Description
Card8 format =3
Card16 nRanges Number of ranges
struct Range3 [nRanges] Range3 array (see Table 16)
Card16 sentinel Sentinel GID (see below)

The format of a Range3 is shown in Table 16.

Table 16 FDSelect Range3 Format

Type Name Description
Card16 first First glyph index in range
Card8 fd FD index for all glyphs in range

Format 4 differs from Format 3 only in that it accomodates more than 65536 glyphs, by using a Card32 type for thenRangesandsentinelfields, and the Range4 type for theRange4array.

Table 17 FDSelect Format 4

Type Name Description
Card8 format =4
Card32 nRanges Number of ranges
struct Range4 [nRanges] Range4 array (see Table 18)
Card32 sentinel Sentinel GID (see below)

The format of a Range4 is shown in Table 18.

Table 18 FDSelect Range4 Format

Type Name Description
Card32 first First glyph index in range
Card16 fd FD index for all glyphs in range

The Range4 format differs from the Range3 only in that it accomodates more than 65536 glyphs, by using a Card32 type for thefirstfield and a Card16 field for the elements of thefdarray)

12. Private DICT Data

The names of the Private DICT operators shown in Table 10 are, where possible, the same as the corresponding Type 1 dict keys. Operators that have no corresponding Type 1 dict key are indicated with a note in Table 19.

Table 19 Private DICT Operators 

Name Value Operand(s) Default, notes
BlueValues 6 delta –
OtherBlues 7 delta –
FamilyBlues 8 delta –
FamilyOtherBlues 9 delta –
BlueScale 12 9 number 0.039625
BlueShift 12 10 number 7
BlueFuzz 12 11 number 1
StdHW 10 number –
StdVW 11 number –
StemSnapH 12 12 delta –
StemSnapV 12 13 delta –
LanguageGroup 12 17 number 0
ExpansionFactor 12 18 number 0.06
vsindex 22 number 0, itemVariationData index in the VariationStore structure table.
blend 23 delta, number of blends -, Leaves 'number of blends' values on the operand stack.
Subrs 19 number –, Offset (self) to local subrs

The local subrs offset is relative to the beginning of the Private DICT data.

Note that, unlike CFF 1.0, the CFF 2 format does not store the advance widths for glyphs. These must be taken from hmtx and vmtx tables, and, for variable fonts, from the HVAR and VVAR tables.

The OtherBlues and FamilyOtherBlues operators must occur after the BlueValues and FamilyBlues operators, respectively.

A Private DICT is required, but may be specified as having a length of 0 if there are no non-default values to be stored.

13. OpenType Font Variations Extensions

In order to support glyph variation data in CFF2 tables, four new operators are added in CFF 2 format: vsindex, blend, vstore, and maxstack.

A variable font holds data representing the equivalent of several distinct design variations, and uses algorithms for interpolation — or blending — between these designs to derive a continuous range of design instances. This allows an entire family of fonts to be represented by a single variable font. For example, a variable font may contain data equivalent to Light and Heavy designs from a family, which can then be interpolated to derive instances for any weight in between Light and Heavy. Moreover, the single variable font provides even greater functionality since it supports a continuous range of variation between those source designs.

See the chapter, OpenType Font Variations Overview for general background on OpenType Font Variations, details on the tables used to support a variable font, terminology, and a specification of the interpolation algorithm used to blend values to derive specific design instances.

Outline data for a variable font in the CFF 2 format is built much like a non-variable CFF2 table would be built, with exactly the same structure and operators as would be used for the default design representation. However, wherever a value occurs in the default design, the single value for the one design is replaced with a set of delta values, followed by the blend operator. (For efficiency, the blend operator is actually called only at the end of a series of such delta sets, rather than after each one.)

Within a variable font, different glyphs can use different sets of regions and associated delta values for the blending operation. When processing a given glyph, the interpreter must determine which set to use. These sets are stored in the CFF2 table in an ItemVariationStore structure. The ItemVariationStore contains one or more ItemVariationData subtables, each of which contains a list of Variation Regions. The first ItemVariationData subtable defines the default subtable to use, when no other has been specified. When a ItemVariationData subtable other than the default is needed for a set of delta values, the vsindex operator is used. When this operator is used in a Private DICT to set a non-default itemVariationData index, this then becomes the default Item Variation Data index for not only the Private DICT, but also all CharStrings that reference that Private DICT, until the vsindex operator is used again.

Syntax for Font Variations support operators.

vsindex ivs vsindex (22)

Sets the scalars for blending a set of delta values, using the itemVariationData index specified by the unsigned integer index ivs. The index ivs is interpreted as a variation store itemVariationData index for the VariationStore structure. If the vsindex operator is not present in a Private DICT, then the default value is vsindex value is 0. When present, it must be the first operator in the Private DICT. It also sets the default vsindex value for all CharStrings that reference the Private DICT.

blend num(0,0)...num(0,n-1), num(0,0)...num(k-1,0)… num(0,n-1)...num(k-1,n-1) n blend (23) val(0)...val(n-1)

for k delta value operands, produces n interpolated result value(s) from n*k arguments.

The blend operator uses the same set of delta values as used in the TrueType blending model. n is the number of values that will be left on the stack for the next operator. This is passed as the last argument on the stack, and lets the blend operator know that it is preceeded by n+1 groups of operands. The first group contains n arguments that are the actual n values on the stack from the default design. The following n groups each contain k delta values, where k is the number of regions other than the default design. In each of these following groups, the num(i,j) value is for item j on the default design operand stack, and is the delta value for region k. For example, consider an rmoveto operator in a glyph with 3 master source designs and and two design axes, Weight and Width, where the 'Light' master source design is used to provide the default design, and 'Bold' and 'Condensed' are used to provide the regions and delta values for the opposite extremes of the Weight and Width axes.

The first group of arguments are the n values from the default design:

100 150

For each following group i for i = 0 to n-1, the values are for stack element i for from each design other than the default. Parentheses are added here to denote each group.

(100 150) (100 50) (300 100) 2 blend rmoveto

The actual arguments in the groups after the first group are delta values, rather than the actual design values: the difference between the value for the region and the default design value:

(100 150) (0 -50) (150 -50) 2 blend rmoveto.

See the chapter OpenType Font Variations Overview for a full discussion of the calculation of delta values, which is usually more complex than shown in this simple case.

vstore offset vstore (24)

Provides the offset to the VariationStore structure in the CFF2 table.

maxstack num maxstack (25)

Overrides the default maximum argument stack value of 193.

Item Variation Store Contents

The Item Variation Store structure contains variation data and is required for a CFF2 table in a variable font. See Variation Data Tables and Miscellaneous Requirements in the OpenType Font Variations Overview chapter for a complete list of the tables required to support a variable font. Complete details on the Item Variation Store format and related formats are defined in the chapter, OpenType Font Variations Common Table Formats. A brief description follows.

An Item Variation Store contains two important lists. The first list is data that describes the region of influence in variation space for each design that is used in the variable font. Each of these is called a Variation Region. The entire list of Variation Regions is called a Variation Region List.

The second list is of structures of type ItemVariationData that each specify a set of Variation Regions, as a list of indices into the Variation Region List. These are needed because different glyphs may use different sets of regions. By default, there is only one itemVariationData structure, and hence only one set of regions that is used by all glyphs. If more than one set of regions are needed, then an itemVariationData structure is added to define each set. The glyphs that reference a particular itemVariationData item must use the vsindex operator to specify the index of the itemVariationData in the Variation Store list, if the index is other than the default value of 0. The vsindex operator may be used in the Private DICT to set the itemVariationData structure for all glyphs which reference the Private DICT, or in specific CFF 2 CharStrings. If used in either, the last one seen sets the current itemVariationData index to use.

An example of a Variation Store structure in a CFF2 table can be seen in Appendix A. Example CFF 2 Font.

Appendix A Example CFF 2 Font

This appendix illustrates the CFF format with an example font.

- Coming soon -

Appendix B Related Documentation

The following documents may be consulted for further information on Adobe font technology. All are available at Adobe Font Technical Notes.

Appendix C CFF DICT Encoding

Table 20. One-byte CFF DICT Operators

Dec Hex Operator Dec Hex Operator
0 00 -Reserved- 18 12 Private
1 01 -Reserved- 19 13 Subrs
2 02 -Reserved- 20 14 -Reserved-
3 03 -Reserved- 21 15 -Reserved-
4 04 -Reserved- 22 16 vsindex
5 05 -Reserved- 23 17 blend
6 06 BlueValues 24 18 vstore
7 07 OtherBlues 25 19 maxstack
8 08 FamilyBlues 26 1a -Reserved-
9 09 FamilyOtherBlues 27 1b -Reserved-
10 0a StdHW 282 1c shortint
11 0b StdVW 29 1d longint
121 0c escape 30 1e BCD
13 0d -Reserved- 31 1f -Reserved-
14 0e -Reserved- 32–246 20–f6 <numbers>
15 0f -Reserved- 247–2543 f7–fe <numbers>
16 10 -Reserved- 255 ff -Reserved-
17 11 CharStrings

1. First byte of a 2-byte operator.

2. First byte of a 3-byte sequence specifying a number.

3. First byte of a 2-byte sequence specifying a number.

Table 21.Two-byte CFF DICT Operators

Dec Hex Operator Dec Hex Operator
12 0 0c 00 -Reserved- 12 21 0c 15 -Reserved-
12 1 0c 01 -Reserved- 12 22 0c 16 -Reserved-
12 2 0c 02 -Reserved- 12 23 0c 17 -Reserved-
12 3 0c 03 -Reserved- 12 24 0c 18 -Reserved-
12 4 0c 04 -Reserved- 12 25 0c 19 -Reserved-
12 5 0c 05 -Reserved- 12 26 0c 1a -Reserved-
12 6 0c 06 -Reserved- 12 27 0c 1b -Reserved-
12 7 0c 07 FontMatrix 12 28 0c 1c -Reserved-
12 8 0c 08 -Reserved- 12 29 0c 1d -Reserved-
12 9 0c 09 BlueScale 12 30 0c 1e -Reserved-
12 10 0c 0a BlueShift 12 31 0c 1f -Reserved-
12 11 0c 0b BlueFuzz 12 32 0c 20 -Reserved-
12 12 0c 0c StemSnapH 12 33 0c 21 -Reserved-
12 13 0c 0d StemSnapV 12 34 0c 22 -Reserved-
12 14 0c 0e -Reserved- 12 35 0c 23 -Reserved-
12 15 0c 0f -Reserved- 12 36 0c 24 FDArray
12 16 0c 10 -Reserved- 12 37 0c 25 FDSelect
12 17 0c 11 LanguageGroup 12 38 0c 26 FontName
12 18 0c 12 ExpansionFactor 12 39– 12 255 0c 27– 0c ff -Reserved-
12 19 0c 13 -Reserved-
12 20 0c 14 -Reserved-

Appendix D Changes From CFF 1.0

D1. CFF Version Identification

A font with CFF 2 font data must use the sfnt table tag 'CFF2' for the table, and the table major version must be set to 2.

D2. DICT Layout

The following CFF 1.0 INDEX tables are removed from CFF2 tables:

The CFF 2 header differs from the CFF 1.0 header in that the 4th field now represents the length of the Top DICT data structure. See section 6. Header.

The Top DICT data starts immediately after the header data. The fixed data layout order in the CFF 2 format is:

The following INDEX tables are accessed by offsets specified in the TopDICT or Private DICT

D3. Top DICT Data

The Top DICT does not reference a Private DICT directly: instead, it uses the FDArray operator to reference a Font DICT INDEX, which is always present. The Font DICT INDEX will always contain at least one Font DICT. If the Font DICT INDEX contains more than one Font DICT, then the CFF Top DICT must also reference the FDSelect structure.

The CFF Top DICT operators which can be derived from other OpenType tables, or which are no longer used, have all been removed from the CFF 2 format specification. CFF2 tables must not contain these operators: it is an error if they do.

The allowed operators are:

The removed operators are as follows.

D4. Private DICT Data

Two new operators are added, vsindex and blend. See section 13. OpenType Font Variations Extensions.

Several Private DICT operators are removed. The removed operators are:

D5. CharString Data

Type 2 CharStrings must not contain a value for width: a CFF2 table does not contain any CharString width data.

The CharString operator set is extended in the CFF 2 format to include the vsindex and blend operators. These work as described above in section 13. OpenType Font Variations Extensions, but have different operator codes. The CharString operator code for blend is 16, and 15 for vsindex.

For CFF2 tables, the fill rule for CharStrings must always be the nonzero winding number rule, rather than the even-odd rule. This is required for Font Variations support, as CFF 2 variable fonts will have glyphs with paths that overlap. Even for Western fonts, it is difficult to design source master fonts that are blend-compatible without overlap; for ideographic fonts, this is prohibitively difficult.

The default maximum stack depth is increased from 48 to 193. Since the blend operator requires that for each value left on the stack, there be a value on the stack from each contributing font design, this limits the number of regions supported. A stack limit of 193 allows the 'blend operator' to support up to 192 regions, or 31 regions for a single rrcurveto operator. Note that the max stack value is a default value; may be increased by the maxstack operator in the CFF 2 Top DICT. This operator may be used only once, and will set the max stack value for all charstrings in the font. There are some extreme Adobe font data sets which require a maxstack of 513, for glyphs which have 512 source master designs.

Removed CharString Operators

The endchar and return Type 2 operators are removed.

The logic, storage, and math operators are removed. The list of removed operators follows.

D6. External Tables

6.1 Width Data

CFF2 tables do not contain CharString width data in the CFF2 table. This must be derived from the 'HVAR' and 'VVAR' tables, in addition to the 'hmtx' and 'vmtx' tables. The variation data is selected by using the glyph index as an item index to find the relevant delta-set row item, for lsb and advance width.

Glyph bounding box data can be derived only by interpreting the CharString, as with CFF 1.0 font data.

Appendix E Changes Since Earlier Versions

The following changes and revisions have been made since the initial publication date of 2 Sep 2016.

This page was last updated 6 September 2016.

© 2016 Microsoft Corporation. All rights reserved. Terms of use.

Comments to the MST group: how to contact us.

Microsoft Typography | Developer... | OpenType specification | OpenType tables | The CFF2 table