CFF2 — Compact Font Format (CFF) Version 2 (OpenType 1.8.1)

Article
06/09/2022

1 Introduction

This document describes the CFF2 format. Like the CFF 1.0 format, CFF2 allows efficient storage of glyph outlines and metadata. The CFF2 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 CFF2 format adds new operators which allows CFF2 to represent the data for a variable font: a font that includes representations for several different variants of each glyph, which can be blended to produce an intermediate instance. See the chapter OpenType Font Variations Overview for a general overview of variable fonts and for a complete list of the tables required to support a variable font.

Finally, the CFF2 format requires the use of CFF2 CharStrings rather than Type 2 CharStrings. This CharString format, like the CFF2 format itself, has removed operators to reduce file size, and added new operators to support variable fonts. See section 8, CharStrings INDEX, for additional information on CFF2 CharStrings.

For a complete description of the differences between CFF format version 1.0 and CFF2, 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 CFF2 Data Layout

Entry	Comments
Header	Fixed location
Top DICT	Fixed location
Global Subr INDEX	Fixed location
VariationStore
FDSelect	Present only if there is more than one Font DICT in the Font DICT INDEX.
Font DICT INDEX
Array of Font DICT	Included in Font DICT INDEX.
Private DICT	One per Font DICT.

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

3. Data Types

This section describes data representation and types used by the CFF2 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 CFF2 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 CFF2 data, and (self) to indicate an offset relative to the data structure containing the offset.

The data types used in the CFF2 table are shown in Table 2.

Table 2 CFF2 Data Types

Name	Range	Description
uint8	0 to 255	8-bit unsigned number
uint16	0 to 65535	16-bit unsigned number
uint32	0 to 4294967295	32-bit unsigned number
Offset	varies	1, 2, 3, or 4 byte offsets (specified by OffSize field in an Index table)
OffSize	1 to 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 CFF2 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 CharStrings. Dictionary keys are encoded as 1- or 2-byte operators and dictionary values are encoded as variable-size numeric operands. 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. There are three structures that use the DICT Data format: Top DICT, Font DICT and Private DICT. A list of DICT operators for each of these may be found in section 7, Top DICT, section 10, Font DICT, and section 11, Private DICT.

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 to 246	-107 to +107	b0 – 139
2	247 to 250	+108 to +1131	(b0 – 247) * 256 + b1 + 108
2	251 to 254	-1131 to -108	-(b0 – 251) * 256 – b1 – 108
3	28	-32768 to +32767	b1 << 8 \| b2
5	29	-(2^31) to +(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 CFF2 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 value	Represents
0 to 9	0 to 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. Values 28, 29, 30, and 32 to 254 specify operands (numbers). All other values either specify an operator or are reserved. The maximum number of operands which may precede an operator is set by the current stack limit.

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
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 a₀, a₁, a₂, ..., an would be encoded as: a₀ (a₁ – a₀) (a₂ – a₁) ..., (a_n – 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.

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
uint32	count	Number of objects stored in INDEX
OffSize	offSize	Offset array element size
Offset	offset [count+1]	Offset array (from byte preceding object data)
uint8	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 4 bytes.

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

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

Table 8 Header Format

Type	Name	Description
uint8	majorVersion	Format major version. Set to 2.
uint8	minorVersion	Format minor version. Set to zero.
uint8	headerSize	Header size (bytes)
uint16	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 DICT of the CFF2 table.

The names of the Top DICT operators and default values (where applicable) are shown in Table 9. Where possible these are the same as the corresponding Type 1 dict key.

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 INDEX offset (0)
FDArray	12 36	number	—	Font DICT (FD) INDEX offset (0)
FDSelect	12 37	number	—	FDSelect structure offset (0)
vstore	24	number	—	VariationStore structure offset (0)
maxstack	25	number	193	Maximum argument stack for all CFF2 Private DICT and CFF2 CharString operators.

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

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

Operators in Top and Font DICTs may be preceded by up to a maximum of 193 operands. The maximum argument stack may be changed by the maxstack operator in the CFF2 Top DICT; this will set the maximum stack value for all CharStrings and Private DICTs. The permitted range of values is 193 to 513 inclusive.

8. CharStrings INDEX

The CharStrings INDEX is an INDEX structure that contains all of the CFF2 glyphs in the font. Each CharString provides the definition of a glyph and is accessed by glyph index (“GID”). The first CharString (GID 0) must be the .notdef glyph. The number of glyphs defined in the CFF2 table may be determined from the CharString INDEX count field. This must match the numGlyphs field in the 'maxp' table.

The format of the CharString data for CFF2 data, and therefore the method of interpretation, is the CFF2 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 CFF2 CharString Format for details. The major changes are as follows:

CFF2 CharStrings do not contain a value for advance width.
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 in order to support variable font data, in which it is not practical to enforce removal of overlaps between paths.
The maximum stack depth allowed is changed from 48 to a variable value, with a default value of 193.
The CharString operator set is extended in CFF2 to include the blend(15) and vsindex (16) operators. These work as described below, in relation to equivalent CFF2 Private DICT operators, in section 12, Extensions for OpenType Font Variations. Note, however, that the operator codes for these operators when used in CharStrings is different from the operator codes for the equivalent CFF2 Private DICT operators.
The Type 2 operators endchar and return are removed.
The Type 2 logic, storage, and math operators are removed.

The CFF2 format does not contain glyph names or CID values for glyph tags. Glyph tags that provide some semantic content can be useful for debugging, however, and can also be used as a last resort for deriving encoding information. Glyph tags for CFF2 tables can be represented by PostScript glyph names in a version 2.0 'post' table. Glyph names add to the size of a font and are optional. Alternatively, the font can use a version 3.0 'post' table, which omits glyph names.

9. Local and Global Subr INDEXes

A subroutine (“subr”) is typically a sequence of CharString bytes representing a sub-program that is used in more than one place in a font’s CharString data. A subr may be stored once but referenced many times from within one or more CharStrings by the use of a call-subroutine operator that takes as an operand the number of the subr to be called.

Some subrs are local; that is, they are contained within a Private DICT and accessible by the set of CharStrings associated with the Private Dict. Local subrs are contained within an INDEX structure; the offset of the INDEX within the Private DICT is specified using the Subrs operator. A CharString references a local subr in its Private DICT by means of the callsubr operator.

Subrs can also be global, accessible to any CharString within the font. Global subrs are stored in the Global Subrs INDEX, which follows the Top DICT data. A font might not have any global subrs, in which case the Global Subrs INDEX is empty. A CharString references a global subr by means of the callgsubr operator.

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

uint16 bias;
uint16 nSubrs = subrINDEX.count;
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.

10. Font DICT INDEX, Font DICTs and FDSelect.

The Font DICT INDEX contains one or more FontDICT structures. Unlike CID-keyed Type 1 fonts, the Font DICT INDEX may contain more than 256 Font DICTs.

A Font DICT is used for hinting, variation or subroutine (subr) data used by CharStrings. A font can have one Font DICT, which would apply to all CharStrings, or it can have multiple Font DICTs, each applicable to some set of CharStrings. The actual hinting or other data is contained in a Private DICT. Each Font DICT structure provides a reference to a Private DICT.

Table 10 Font DICT Operator Entries

Name	Value	Operand(s)	Default	Notes
Private	18	number	—	Private DICT size and offset (0)
FontMatrix	12 7	array	0.001 0 0 0.001 0 0

If there are multiple Font DICTs, an FDSelect table is used to provide information about which Font DICT (“FD”) is used for which glyphs. An FDSelect is used only if there are multiple Font DICTS.

The location of the FDSelect table is given as the operand of the FDSelect operator in the Top DICT. An FDSelect table associates a 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. Three formats for the FDSelect table are currently defined, as shown in the following tables.

<a id="Table11"Table 11 FDSelect Format 0

Type	Name	Description
uint8	format	Set to 0
uint8	fds [nGlyphs]	FD selector array

Each element of the fds array represents the FD index of a Font DICT in the FDArray. This format should be used when the FD indices are in a fairly random order. The number of glyphs (nGlyphs) is the value of the count field in the CharStrings INDEX.

Table 12 FDSelect Format 3

Type	Name	Description
uint8	format	Set to 3
uint16	nRanges	Number of ranges
Range3	range3 [nRanges]	Array of Range3 records (see below)
uint16	sentinel	Sentinel GID

The format of a Range3 record is as follows:

Table 13 Range3 Record Format

Type	Name	Description
uint16	first	First glyph index in range
uint8	fd	FD index for all glyphs in range

Each Range3 describes a group of sequential GIDs that have the same FD index. Each range includes GIDs from the first GID in the range record up to, but not including, the first GID of the next range record. Records in the Range3 array must be in increasing order of first GIDs. The first range must have a first GID of 0. A sentinel GID follows the last range element and serves to delimit the last range in the array. The sentinel GID is set equal to the number of glyphs in the font. That is, its value is 1 greater than the last GID in the font. This format is particularly suited to FD indexes that are well ordered (the usual case).

Table 14 FDSelect Format 4

Type	Name	Description
uint8	format	Set to 4
uint32	nRanges	Number of ranges
Range4	range4 [nRanges]	Array of Range4 records (see below)
uint32	sentinel	Sentinel GID

Format 4 differs from Format 3 only in that it accomodates more than 65536 glyphs by using a uint32 type for the nRanges and sentinel fields, and a Range4 record array.

The format of a Range4 record is as follows:

Table 15 Range4 Record Format

Type	Name	Description
uint32	first	First glyph index in range
uint16	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 uint32 for the first GID field and a uint16 field for the FD index.

Note: While FDSelect format 4 allows for more than 65536 glyphs, other parts of the OpenType format, such as the numGlyphs field of the 'maxp' table, are still constrained to 65536 glyphs.

11. Private DICT Data

The names of the Private DICT operators shown in Table 16 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 16.

Table 16 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.

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 size of 0 if there are no non-default values to be stored.

12. Extensions for OpenType Font Variations

In order to support glyph variation data in CFF2 tables, four new operators are added in CFF2 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 a continuous range between Light and Heavy.

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 CFF2 format are 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 supplemented with a set of delta values, followed by the blend operator. (For efficiency, a single blend operator may follow a series of such delta sets, rather than after each individual set.) Unlike other DICT operators, blend does not clear the stack when it is processed. The result of the blend operator remains on the stack to be processed by the following operator.

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 (index 0) is used by default when no other subtable has been specified. When an 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 for all CharStrings that reference that Private DICT. When the vsindex operator is used in a CharString, it supersedes any vsindex from the private DICT. All private DICTs and CharStrings in a CFF2 table share the same ItemVariationStore.

Syntax for Font Variations support operators.

vsindex

|- ivs vsindex (22) |-

Selects the ItemVariationData subtable to be used for blending; the ivs argument is the ItemVariationData index. When used, vsindex must precede the blend operator.

Note that the operator code, 22, is different from the equivalent CharStrings operator. This operator may be used only in a Private DICT.

blend

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

For k regions, produces n interpolated result value(s) from n*(k + 1) operands. For more information and examples, see the description of the equivalent CharString operator in section 4.5, Variation Data Operators, in the CFF2 CharString Format chapter.

Note that the operator code, 23, is different from the equivalent CharStrings operator. This operator may only be used in a Private DICT.

vstore

|- offset vstore (24) |-

Provides the offset to the VariationStore data in the CFF2 table. This operator may only be used in the Top DICT.

maxstack

|- num maxstack (25) |-

Overrides the default maximum argument stack value of 193. This operator may only be used in the Top DICT and affects the argument stack for both Private DICTs and CharStrings.

VariationStore Data Contents

The VariationStore data is comprised of two parts: a uint16 field that specifies a length, followed by an Item Variation Store structure of the specified length. The Item Variation Store format is specified in the chapter OpenType Font Variations Common Table Formats. A brief description of the format as used within the CFF2 table follows.

To support variation of glyphs or other font data, the information used is comprised of default values for the particular data item, a set of delta adjustment values used to modify the default value, and a set of regions within the font’s variation space over which the different delta values apply. The Item Variation Store format is designed to accommodate both the set of regions and the delta values. Within the CFF2 table, the Item Variation Store is used to represent the different regions, but the delta values are interleaved within the CharStrings where they are used.

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 an array of ItemVariationData structures that each specify a set of Variation Regions, as a list of indices into the Variation Region List. This allows different glyphs to have delta values that apply to different sets of regions. There is often 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 vsindex operator may be used in a Private DICT to set the itemVariationData index for all glyphs which reference the Private DICT, or it may be used in specific CFF2 CharStrings when a CharString needs to use a different ItemVariationData structure than is specified in the Private DICT.

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

Appendix A Example CFF2 Font

This appendix illustrates the CFF2 format with an example CFF2 table.

Binary dump (226 bytes):

0000: 02 00 05 00 07 CF 0C 24 C3 11 9B 18 00 00 00 00
0010: 00 26 00 01 00 00 00 0C 00 01 00 00 00 1C 00 01
0020: 00 02 C0 00 E0 00 00 00 C0 00 C0 00 E0 00 00 00
0030: 00 00 00 02 00 00 00 01 00 00 00 02 01 01 03 05
0040: 20 0A 20 0A 00 00 00 01 01 01 05 F7 06 DA 12 77
0050: 9F F8 6C 9D AE 9A F4 9A 95 9F B3 9F 8B 8B 8B 8B
0060: 85 9A 8B 8B 97 73 8B 8B 8C 80 8B 8B 8B 8D 8B 8B
0070: 8C 8A 8B 8B 97 17 06 FB 8E 95 86 9D 8B 8B 8D 17
0080: 07 77 9F F8 6D 9D AD 9A F3 9A 95 9F B3 9F 08 FB
0090: 8D 95 09 1E A0 37 5F 0C 09 8B 0C 0B C2 6E 9E 8C
00A0: 17 0A DB 57 F7 02 8C 17 0B B3 9A 77 9F 82 8A 8D
00B0: 17 0C 0C DB 95 57 F7 02 85 8B 8D 17 0C 0D F7 06
00C0: 13 00 00 00 01 01 01 1B BD BD EF 8C 10 8B 15 F8
00D0: 88 27 FB 5C 8C 10 06 F8 88 07 FC 88 EF F7 5C 8C
00E0: 10 06

Analysis:

Hex data	Source	Comments
	Header	CFF2 offsets: 0000 to 0004
02	majorVersion	= 2
00	minorVersion	= 0
05	headerSize	= 5
00 07	topDictSize	= 7
	Top DICT Data	CFF2 offsets: 0005 to 000B
CF 0C 24	\|- offset FDArray \|-	= 68 FDArray The bytes 0C 24 represent the FDArray operator. The operand byte is hex CF = decimal 207, which is decoded using the rule for byte values from 32 to 246 (see Table 3, Operand Encoding): b0 - 139. This gives the offset of the Font DICT INDEX: decimal 68 = hex 44.
C3 11	\|- offset CharStrings \|-	= 56 CharStrings The byte 11 represents the CharStrings operator. The operand byte is hex C3, which is the encoded representation of the value 56. This gives the offset of the CharStrings INDEX: decimal 56 = hex 38.
9B 18	\|- offset vstore \|-	= 16 vstore The byte 18 represents the vstore operator. The operand byte is hex 9B, which is the encoded representation of the value 16. This gives the offset of the VariationStore Data: decimal 16 = hex 10.
	Global Subr INDEX	CFF2 offsets: 000C to 000F
00 00 00 00	count	= empty INDEX; no additional fields represented.
	VariationStore Data	CFF2 offsets: 0010 to 0037
00 26	length	= 38 — length in bytes of the Item Variation Store structure that follows.
	ItemVariationStore	CFF2 offsets: 0012 to 0037
00 01	format	= 1
00 00 00 0C	offsetToVariationRegionList	= 12 — offset in bytes from the start of the ItemVariationStore.
00 01	itemVariationDataCount	= 1 — number of ItemVariationData subtables.
00 00 00 1C	itemVariationDataOffsets[0]	= 28 — offset in bytes from start of the ItemVariationStore to ItemVariationData subtable 0.
	VariationRegionList	CFF2 offsets: 001E to 002D
00 01	axisCount	= 1
00 02	regionCount	= 2
	variationRegions[0]	CFF2 offsets: 0022 to 0027
	regionAxes[0]	CFF2 offsets: 0022 to 0027
C0 00	startCoord	= -1.0 (F2DOT14 value)
E0 00	peakCoord	= -0.5 (F2DOT14 value)
00 00	endCoord	= 0.0 (F2DOT14 value)
	variationRegions[1]	CFF2 offsets: 0028 to 002D
	regionAxes[0]	CFF2 offsets: 0028 to 002D
C0 00	startCoord	= -1.0 (F2DOT14 value)
C0 00	peakCoord	= -1.0 (F2DOT14 value)
E0 00	endCoord	= -0.5 (F2DOT14 value)
	ItemVariationData subtable 0	CFF2 offsets: 002E to 0037
00 00	itemCount	= 0
00 00	shortDeltaCount	= 0
00 02	regionIndexCount	= 2
00 00 00 01	regionIndexes[]	= {0, 1}
	CharStrings INDEX	CFF2 offsets: 0038 to 0043
00 00 00 02	count	= 2
01	offSize	= 1
01 03 05	offset[]	= {1, 3, 5} (number of elements is count + 1)
	CharString 0	CFF2 offsets: 0040 to 0041
20 0A	\|- subr# callsubr \|-	= -107 callsubr The byte 0A represents the callsubr operator. The operand byte is 20, which is the encoded representation of the value -107.
	CharString 1	CFF2 offsets: 0042 to 0043
20 0A	\|- subr# callsubr \|-	= -107 callsubr The byte 0A represents the callsubr operator. The operand byte is 20, which is the encoded representation of the value -107.
	Font DICT INDEX	CFF2 offsets: 0044 to 004E
00 00 00 01	count	= 1
01	offSize	= 1
01 05	offset[]	= {1, 5} (number of elements is count + 1)
	Font DICT 0	CFF2 offsets: 004B to 004E
F7 06 DA 12	\|- size offset Private \|-	= 114 79 Private The byte 12 represents the Private operator. The operand bytes F7 06 are the encoded representation of the value 114. The operand byte DA is the encoded representation of the value 79. This gives the size and offset of a Private DICT: size is 114 bytes, offset (from start of CFF2 table) is 79 bytes (hex 4F).
	Private DICT	CFF2 offset: 004F to 00C0
77 9F F8 6C 9D AE 9A F4 9A 95 9F B3 9F 8B 8B 8B 8B 85 9A 8B 8B 97 73 8B 8B 8C 80 8B 8B 8B 8D 8B 8B 8C 8A 8B 8B 97 17 06	\|- num* blend BlueValues \|-	= -20 20 472 18 35 15 105 15 10 20 40 20 0 0 0 0 -6 15 0 0 12 -24 0 0 1 -11 0 0 0 2 0 0 1 -1 0 0 12 blend BlueValues The byte 06 represents the BlueValues operator. The byte 17 represents the blend operator. The operand bytes 77.. 97 are the encoded representation of the values -20... 12.
FB 8E 95 86 9D 8B 8B 8D 17 07	\|- num* blend OtherBlues \|-	= -250 10 -5 18 0 0 2 blend OtherBlues The byte 07 represents the OtherBlues operator. The byte 17 represents the blend operator. The operand bytes FB.. 8D are the encoded representation of the values -250... 2.
77 9F F8 6D 9D AD 9A F3 9A 95 9F B3 9F 08	\|- num* FamilyBlues \|-	= -20 20 473 18 34 15 104 15 10 20 40 20 FamilyBlues The byte 08 represents the operator FamilyBlues. The operand bytes 77... 9F are the encoded representation of the values -20... 20.
FB 8D 95 09	\|- num* FamilyOtherBlues \|-	= -249 10 FamilyOtherBlues The byte 09 represents the FamilyOtherBlues operator. The operand bytes FB 8D are the encoded representation of the value -249. The operand byte 95 is the encoded representation of the value 10.
1E A0 37 5F 0C 09	\|- num BlueScale \|-	= 0.0375 BlueScale The bytes 0C 09 represent the BlueScale operator. The operand bytes 1E A0 37 5F are the encoded representation of the value 0.0375.
8B 0C 0B	\|- num BlueFuzz \|-	= 0 BlueFuzz. The bytes 0C 0B represents the BlueFuzz operator. The operand byte 8B is the encoded representation of the value 0.
C2 6E 9E 8C 17 0A	\|- num* blend StdHW \|-	= 55 -29 19 1 blend StdHW The byte 0A represents the StdHW operator. The byte 17 represents the blend operator. The operand bytes C2 6E 9E 8C are the encoded representation of the values 55 -29 19 1.
DB 57 F7 02 8C 17 0B	\|- num* blend StdVW \|-	= 80 -52 110 1 blend StdVW The byte 0B represents the StdVW operator. The byte 17 represents the blend operator. The operand bytes DB 57 F7 02 8C are the encoded representation of the values 80 -52 110 1.
B3 9A 77 9F 82 8A 8D 17 0C 0C	\|- num* blend StemSnapH \|-	= 40 15 -20 20 -9 -1 2 blend StemSnapH The bytes 0C 0C represent the StemSnapH operator. The byte 17 represents the blend operator. The operand bytes B3 9A 77 9F 82 8A 8D are the encoded representation of the values 40 15 -20 20 -9 -1 2.
DB 95 57 F7 02 85 8B 8D 17 0C 0D	\|- num* blend StemSnapV \|-	= 80 10 -52 110 -6 0 2 blend StemSnapV The bytes 0C 0D represent the StemSnapV operator. The byte 17 represents the blend operator. The operand bytes DB 95 57 F7 02 85 8B 8D are the encoded representation of the values 80 10 -52 110 -6 0 2.
F7 06 13	\|- num Subrs \|-	= 114 Subrs The byte 13 represents the Subrs operator. The operand bytes F7 06 are the encoded representation of the value 114. This gives the offset (from the start of the Private DICT) to the local Subr INDEX: 114 bytes (hex 72).
	Local Subr INDEX	CFF2 offsets: 00C1 to 00E1
00 00 00 01	count	= 1
01	offSize	= 1
01 1B	offset[]	= {1, 27} (number of elements is count + 1)
	subr 0	CFF2 offsets: 00C8 to 00E1
BD BD EF 8C 10 8B 15	\|- num* blend num rmoveto \|-	= 50 50 100 1 blend 0 rmoveto The byte 15 represents the rmoveto CharString operator. The byte 10 represents the blend CharString operator. The operand bytes BD BD EF 8C are the encoded representation of the values 50 50 100 1. The operand byte 8B is the encoded representation of the value 0.
F8 88 27 FB 5C 8C 10 06	\|- num* blend hlineto \|-	= 500 -100 -200 1 blend hlineto The byte 06 represents the hlineto CharString operator. The byte 10 represents the blend CharString operator. The operand bytes F8 88 27 FB 5C 8C are the encoded representation of the values 500 -100 -200 1.
F8 88 07	\|- num vlineto \|-	= 500 vlineto The byte 07 represents the vlineto CharString operator. The operand bytes F8 88 are the encoded representation of the value 500.
FC 88 EF F7 5C 8C 10 06	\|- num* blend hlineto \|-	= -500 100 200 1 blend hlineto The byte 06 represents the hlineto CharString operator. The byte 10 represents the blend CharString operator. The operand bytes FC 88 EF F7 5C 8C are the encoded representation of the values -500 100 200 1.

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.

The Compact Font Format Specification #5176
The Type 2 CharString format #5177
Generating PostScript Names for Fonts Using OpenType Font Variations #5902

Appendix C CFF2 DICT Encoding

Table 17 One-byte CFF2 DICT Operators

Dec	Hex	Operator	Note
0 to 5	00 to 05	<reserved>
6	06	BlueValues
7	07	OtherBlues
8	08	FamilyBlues
9	09	FamilyOtherBlues
10	0a	StdHW
11	0b	StdVW
12	0c	escape	First byte of a 2-byte operator.
13 to 16	0d to 10	<reserved>
17	11	CharStrings
18	12	Private
19	13	Subrs
20 to 21	14 to 15	<reserved>
22	16	vsindex
23	17	blend
24	18	vstore
25	19	maxstack
26 to 27	1a to 1b	<reserved>
28	1c	<numbers>	First byte of a 3-byte sequence specifying a signed integer value (following two bytes are an int16).
29	1d	<numbers>	First byte of a 5-byte sequence specifying a signed integer value (following four bytes are an int32).
30	1e	BCD
31	1f	<reserved>
32 to 246	20 to f6	<numbers>
247 to 254	f7 to fe	<numbers>	First byte of a 2-byte sequence specifying a number.
255	ff	<reserved>

Table 18 Two-byte CFF2 DICT Operators

Dec	Hex	Operator
12 0 to 12 6	0c 00 to 0c 06	<reserved>
12 7	0c 07	FontMatrix
12 8	0c 08	<reserved>
12 9	0c 09	BlueScale
12 10	0c 0a	BlueShift
12 11	0c 0b	BlueFuzz
12 12	0c 0c	StemSnapH
12 13	0c 0d	StemSnapV
12 14 to 12 16	0c 0e to 0c 10	<reserved>
12 17	0c 11	LanguageGroup
12 18	0c 12	ExpansionFactor
12 19 to 12 35	0c 13 to 0c 23	<reserved>
12 36	0c 24	FDArray
12 37	0c 25	FDSelect
12 33 to 12 255	0c 26 to 0c ff	<reserved>

Appendix D Changes From CFF 1.0

D1. Table Name and Version

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

D2. DICT Layout

The following CFF 1.0 tables are removed from the CFF2 table:

Name INDEX. CFF2 tables do not contain PostScript names. Also, FontSets are not supported in the CFF2 format. When making a CFF 1.0 instance snapshot from a CFF2 table, the PostScript font name can be copied from the name ID 6 value in the 'name' table. For variable fonts, it must be derived via the heuristics specified for variable fonts and the information in the 'fvar' and 'STAT' tables. See Adobe Technical Note 5902, PostScript Name Generation for Fonts Using OpenType Font Variations #5902.
Top DICT INDEX. Since FontSets are not supported in the CFF2 format, there can be only one Top DICT.
String Table. Glyph names, if needed, can be provided in the 'post' table.
Encoding Table. CFF2 tables derive encoding information only from the 'cmap' table.
Charset Table. No longer used. Glyph identifiers are derived from the 'post' table.

The count field of an INDEX is uint32 instead of uint16.

The CFF2 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, for details.

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

Header
Top DICT Data
Global Subr INDEX

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

FDSelect
CharStrings INDEX
VariationStore Data
Font DICT INDEX
Private DICT
Local Subrs INDEX

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 Top DICT must also reference an FDSelect structure.

Two new Top DICT operators have been added: vstore, and maxstack. See section 12, Extensions for OpenType Font Variations for details.

Top DICT operators that can be derived from other OpenType tables or that are no longer used have all been removed from the CFF2 format specification. Use of these operators in a CFF2 table is invalid; if encountered, they must be ignored.

The only CFF 1 Top DICT operators that are permitted in a CFF2 table are the following:

FontMatrix (12 7) array
CharStrings (17) offset
FDArray (12 36) offset
FDSelect (12 37) offset

The following table lists CFF 1 Top DICT operators that are not supported in CFF2, along with details on alternative mechanisms within a CFF2 font:

Table 19 CFF 1 Top DICT Operators Not Used in CFF2

Name	Code (decimal)	CFF2 equivalent
version	0	Equivalent to the fontRevision field in the 'head' table. A CFF 1 version operand can be derived from the fontRevision field, which is a 16.16 Fixed value, and formatting it as a decimal number with three decimal places of precision.
Notice	1	Equivalent to the concatenation of strings from the 'name' table: the Copyright string (name ID 0), a space, followed by the Trademark string (name ID 7).
FullName	2	Equivalent to the Full Name string (name ID 4) in the 'name' table.
FamilyName	3	Equivalent to the Typographic Family Name string (name ID 16) in the 'name' table, if present, else the Famly Name string (name ID 1).
Weight	4	Equivalent to the usWeightClass field in the 'OS/2' table.
FontBBox	5	Approximately equivalent to the combination of the xMin, xMax, yMin and yMax fields in the 'head' table. These will be only approximate, as they will be for the default value only, but are accurate enough if deriving values for CFF 1 interpreters. Some interpreters use these values to influence the hints for global coloring, and some use this to set flattening parameters.
Copyright	12 0	Equivalent to the Copyright string (name ID 0) in the 'name' table.
IsFixedPitch	12 1	Equivalent to the isFixedPitch field in the 'post' table.
ItalicAngle	12 2	Equivalent to the italicAngle field in the 'post' table.
UnderlinePosition	12 3	Equivalent to the underlinePosition field in the 'post' table.
UnderlineThickness	12 4	Equivalent to the underlineThickness field in the 'post' table.
PaintType	12 5	There is no equivalent in a CFF2 font. If deriving CFF 1-compatible data, use the CFF 1 default value of zero.
StrokeWidth	12 8	There is no equivalent in a CFF2 font. In a CFF 1 font, it is used only for PaintType 2. If deriving CFF 1-compatible data, PaintType 0 should be used.
SyntheticBase	12 20	There is no equivalent in a CFF2 font.
PostScript	12 21	There is no equivalent in a CFF2 font. CFF 1 allowed for embedded PostScript code, but this was only ever used in CFF 1 OpenType fonts to provide an FSType key in the Top DICT, to carry the font embedding permissions from the fsType field of the 'OS/2' table. If deriving CFF 1-compatible data, the value can be copied from the 'OS/2' table.
BaseFontName	12 22	There is no equivalent in a CFF2 font.
BaseFontBlend	12 23	There is no equivalent in a CFF2 font.
ROS	12 30	There is no equivalent in a CFF2 font. If generating CFF 1-compatible font instance from a CFF2 variable font that has more than one Font DICT in the Font DICT INDEX, the CFF 1 font must be written as a CID-keyed font. The ROS used should be Adobe-Identity-0. This maps all glyph IDs to a CID of the same value and carries no semantic content.
CIDFontVersion	12 31	There is no equivalent in a CFF2 font. If deriving CFF 1-compatible data, use the CFF 1 default value of zero.
CIFFontRevision	12 32	There is no equivalent in a CFF2 font. If deriving CFF 1-compatible data, use the CFF 1 default value of zero.
CIDFontType	12 33	There is no equivalent in a CFF2 font. If deriving CFF 1-compatible data, use the CFF 1 default value of zero.
CIDCount	12 34	Equivalent to the numGlyphs field in the 'maxp' table.
UIDBase	12 35	No longer required — see comments on UniqueID.
UniqueID	13	No longer required: This was originally used for caching fonts in printers. However, many third-party fonts with conflicting UnicodeID values have made it unreliable. More importantly, performance tests have shown that font caching no longer provides significant performance improvements when printing.
XUID	14	No longer required — see comments on UniqueID.
charset	15	If required, glyph names can be represented in a version 2.0 'post' table.
Encoding	16	Equivalent to the 'cmap' table.
Private	18	No longer required: In a CFF2 font, a Private DICT is always referenced from a Font DICT in the Font DICT INDEX.

D4. Private DICT Data

Two new operators are added that can be used in Private DICTs: vsindex and blend. See section 12, Extensions for OpenType Font Variations Extensions, for more information.

Private DICT operators that are no longer used or that have existing equivalents in other OpenType tables are not used in CFF2. Use of these operators in a CFF2 table is invalid; if encountered, they must be ignored. The following table lists CFF 1 Private DICT operators that are not supported in CFF2, along with details on alternative mechanisms within a CFF2 font:

Table 20 CFF 1 Private DICT Operators Not Used in CFF2

Name	Code (decimal)	CFF2 equivalent
defaultWidthX	(20)	Horizontal glyph metrics for CharStrings in a CFF2 table are obtained from the 'hmtx' and 'HVAR' tables
nominalWidthX	(21)	Horizontal glyph metrics for CharStrings in a CFF2 table are obtained from the 'hmtx' and 'HVAR' tables

Appendix E Changes Since Earlier Versions

The following changes and revisions have been made since the initial publication in OpenType 1.8.

Initial publication: OpenType 1.8 (September 2016). See Appendix D, Changes From CFF 1.0.
OpenType 1.8.1 (January 2017):
- Data types Card8, Card16 and Card32 were replaced by uint8, uint16 and uint32 to match usage with the rest of the OpenType specification.
- All references to FontSets were removed or reworded (FontSets are not supported in CFF2).
- In Table 2, CFF2 Data Types, an entry was added for uint32.
- In section 4, DICT Data, descriptions of operands and operators were revised, and table references were corrected.
- In Table 6 of section 4, Operand Types, the boolean type was deleted (not used in CFF2).
- In section 5, INDEX Data, the size of an empty INDEX was corrected to 4 bytes.
- In section 7, Top DICT Data, the allowable range for maximum stack depth was added, as well as clarification that it affects stack depth for Private DICT and CFF2 CharString operators only.
- Section 8, Glyph Organization, was merged into the following section.
- In section 8 (previously section 9), CharStrings INDEX, text was reworded for better clarity, and a paragraph on glyph names and glyph IDs was added.
- In section 9 (previously section 10), Local and Global Subr INDEXes, text was reworded for better clarity, and the detailed discussion of space savings from subr number bias was removed.
- In section 10 (previously section 11), Font DICT INDEX, Font DICTs and FDSelect, text was reworded for better clarity; a note was added that a Font DICT INDEX can contain more than 256 Font DICTs; the description of sentinel glyph ID was restored; and the reference to FontName was removed (this CFF 1 operator is not used in CFF2).
- In section 11 (previously section 12), Private DICT Data, the paragraph about advance widths was removed.
- In section 12 (previously section 13), the blend operator example was replaced with a reference to the example provided in section 4.5 of “The CFF2 CharString Format” chapter.
- In appendix A, Example CFF2 Font, an example of CFF2 font data was added.
- In appendix C, CFF2 DICT Encoding, formatting changes were made.
- In appendix D, Changes from CFF 1.0, text was reworded in various places.
- In section D2 of appendix D, DICT Layout, a note about the type for the INDEX count field was added, and table references were corrected.
- In section D3 of appendix D, Top DICT Data, CharStringType was removed from the list of supported operators, and details about the supported operators were added. Also, in the description of the CFF 1 ROS operator, “Adobe-Identity-1” was changed to “Adobe-Identity-0”. Other formatting changes were also made.
- In section D4 of appendix D, ForceBold and initialRandomSeed were removed from the list of CFF 1 operators not used in CFF2, and other formatting changes were made.
- Section D5 of appendix D, CharString Data, and also section D6, External Tables, were removed.
- Many changes were made for consistency of terminology, such as consistent capitalization and spelling of “CharString”, “VariationStore”, “CFF2”, and use of “Font DICT INDEX” where that is more appropriate than “FDArray”.

Partager via