CFF 2 – Compact Font Format (CFF) Version 2 (OpenType 1.8)

Artigo
09/22/2020

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:

CFF 2 CharStrings must not contain a value for width: a CFF2 table does not contain any CharString width data.
For CFF2 tables, the fill rule for CharStrings must always be the nonzero winding number rule, rather than the even-odd rule.
The maximum stack depth allowed is increased from 48 to 193¹.
The CharString operator set is extended in CFF 2 to include theblend(23) andvsindex(22) operators. These work as described below in section 13. OpenType Font Variations Extensions, but have different operator codes. The CFF 2 CharString operator code forblendis 16, and 15 forvsindex.
The Type 2 operators endchar and return are removed.
The Type 2 logic, storage, and math operators are removed.
The max argument stack is a default value; it 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.

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:

Ordered index: subr index ordered by most frequent subr first.
Reorder index: ordered index reordered for bias (this is the index of subrs in the local/global Subr INDEX structures).
Biased number: reorder index with bias subtracted (callsubr/callgsubr operand).
Size: biased number size (bytes).
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 the nRanges and sentinel fields, 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 the first field and a Card16 field for the elements of the fd array)

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.

100 150 rmoveto ‘Light’ default design (Weight = 0, Width = 0)
100 300 rmoveto ‘Bold’ design (Weight = 1, Width = 0)
50 100 rmoveto ‘Condensed’ design (Weight = 0, Width = 1)

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.

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

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	28²	1c	shortint
11	0b	StdVW	29	1d	longint
12¹	0c	escape	30	1e	BCD
13	0d	-Reserved-	31	1f	-Reserved-
14	0e	-Reserved-	32–246	20–f6	<numbers>
15	0f	-Reserved-	247–254³	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:

Name INDEX. CFF2 tables do not contain PostScript names; these are derived from named and arbitrary instances from other tables. Also, FontSets are not supported in the CFF 2 format. When making a CFF 1.0 instance snapshot from a CFF2 table, the PostScript font name can be copied from the OpenType 'name' table nameid 6. For variable fonts, it must be derived via the heuristics specified for variable fonts and the information in the 'fvar' table.
Top DICT INDEX. Since FontSets are not supported in the CFF 2 format, there can be only one Top DICT. This single structure replaces the Top DICT INDEX. The last field in the CFF header is now interpreted as the length of the Top DICT data.
Encoding Table. CFF2 tables derive encoding information only from the OpenType ‘cmap table.
Charset Table. No longer used. Glyph identifiers are derived from the 'post' table.

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:

Header
Top DICT Data
Global Subr INDEX

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

FDSelect
CharStrings
FDArray INDEX
Private DICT
Local Sub

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:

FontMatrix
CharStringType
CharStrings
FDArray
FDSelect

The removed operators are as follows.

name code type
version 0 SID
This can be derived by copying the OpenType 'head' fsRevision field, and formatting it as a Fixed with three decimal places of precision.
Notice 1 SID
This can be derived by concatenating the OpenType 'name' table Copyright string (name ID 0) with a space, then the 'name' table Trademark string (name ID 7).
FullName 2 SID
This can be derived by copying the OpenType 'name' table Full Name string (name ID 4).
FamilyName 3 SID
This can be derived by copying the OpenType 'name' table Preferred Family Name string (name ID 16, if present, else name ID 1).
Weight 4 number
This can be derived by copying the OpenType 'OS/2' usWeightClass field.
FontBBox 5 array
This can be derived by copying the xMin,xMax, yMin, yMax fields from the 'head' table. These will be only approximate, as they will be for the default value only, but are accurate enough for the needs of the CFF interpreter. Some interpreters use these values to influence the hints for global coloring, and some use this to set flattening parameters.
Copyright 12 0 SID
This can be derived by copying the OpenType 'name' table Copyright string (name ID 0) .
IsFixedPitch 12 1 number
This can be derived by copying the OpenType 'post' isFixedPitch field.
ItalicAngle 12 2 number
This can be derived by copying the OpenType 'post' italicAngle field.
UnderlinePosition 12 3 number
This can be derived by copying the OpenType 'post' underlinePosition field.
UnderlineThickness 12 4 number
This can be derived by copying the OpenType 'post' underlineThickness field.
PaintType 12 5 number
If needed, the default value of 0 from the CFF 1.0 spec should be used. PaintType 2 (outline, rather than fill) is not supported.
StrokeWidth 12 8 number
This is used only for PaintType 2 Type 1 fonts, and is not supported.
SyntheticBase 12 20 number
This is no longer supported in the CFF 2 format.
PostScript 12 21 SID
No longer supported in the CFF 2 format. The embedded PostScript code was only ever used to provide an FSType key in the TopDICT, to carry the font embedding permissions from the OpenType 'OS/2' table field fsType. It needed, the value can be copied from the OpenType 'OS/2' table field fsType.
BaseFontName 12 22 SID
This is no longer supported in the CFF 2 format.
BaseFontBlend 12 23 SID
This is no longer supported in the CFF 2 format.
ROS 12 30 SID SID number
This is no longer supported in the CFF 2 format. When building a CFF 1.0 font instance from a CFF 2 variable font that has more than one FontDICT in the Font DICT Index, the CFF 1.0 font must be written as a CID-keyed font. The ROS used should be Adobe-Identity-1. This maps all GIDs to a CID of the same value, and carries no semantic content.
CIDFontVersion 12 31 number
If needed, the default value of 0 from the CFF 1.0 spec should be used.
CIDFontRevision 12 32 number
If needed, the default value of 0 from the CFF 1.0 spec should be used.
CIDFontType 12 33 number
If needed, the default value of 0 from the CFF 1.0 spec should be used. CIDCount 12 34 number
This can be derived from the 'maxp' table.
UIDBase 12 35 number
This is removed. See comments on UniqueID .
UniqueID 13 number
This is removed, as it has been some years since it was useful. It was used for caching fonts in printers. However, many third party fonts with conflicting UniqueID values have made it unreliable. More importantly, speed tests show that performance improvements from font caching are no longer significant in printing. ,
XUID 14 array
This is removed. See comments on UniqueID .
charset 15 number
Glyph names can be taken from the OpenType 'post' table.
Encoding 16 number
Encoding information must be taken from the OpenType 'cmap' table.
Private 18 offset
This is removed, as the Private DICT for a font is now always referenced from a Font DICT in the FDArray.

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:

ForceBold 12 14 number
This is no longer used.
initialRandomSeed 12 19 number
This is no longer used.
defaultWidthX 20 number
CharString widths are now derived from the hmtx and HVAR tables.
nominalWidthX 21 number
CharString widths are now derived from the hmtx and HVAR tables.

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.

abs num abs (12 9) num2.
returns the absolute value of num.
add num1 num2 add (12 10) sum
returns the sum of the two numbers num1 and num2.
sub num1 num2 sub (12 11) difference
returns the result of subtracting num2 from num1.
div num1 num2 div (12 12) quotient
returns the quotient of num1 divided by num2. The result is undefined if overflow occurs and is zero for underflow.
neg num neg (12 14) num2
returns the negative of num.
random random (12 23) num2
returns a pseudo random number num2 in the range (0,1], that is, greater than zero and less than or equal to one.
mul num1 num2 mul (12 24) product
returns the product of num1 and num2. If overflow occurs, the result is undefined, and zero is returned for underflow.
sqrt num sqrt (12 26) num2
returns the square root of num. If num is negative, the result is undefined.
drop num drop (12 18)
removes the top element num from the Type 2 argument stack.
exch num1 num2 exch (12 28) num2 num1
exchanges the top two elements on the argument stack.
index numX ... num0 i index (12 29) numX ... num0 numi
retrieves the element i from the top of the argument stack and pushes a copy of that element onto that stack. If i is negative, the top element is copied. If i is greater than X, the operation is undefined.
roll num(N-1) ... num0 N J roll (12 30) num((J-1) mod N) ... num0 num(N-1) ... num(J mod N)
performs a circular shift of the elements num(N-1) ... num0 on the argument stack by the amount J. Positive J indicates upward motion of the stack; negative J indicates downward motion. The value N must be a non-negative integer, otherwise the operation is undefined.
dup any dup (12 27) any any
duplicates the top element on the argument stack.
put val i put (12 20)
stores val into the transient array at the location given by i.
get i get (12 21) val
retrieves the value stored in the transient array at the location given by i and pushes the value onto the argument stack. If get is executed prior to put for i during execution of the current CharString, the value returned is undefined. and num1 num2 and (12 3) 1_or_0
puts a 1 on the stack if num1 and num2 are both non-zero, and puts a 0 on the stack if either argument is zero.
or num1 num2 or (12 4) 1_or_0 puts a 1 on the stack if either num1 or num2 are non-zero, and puts a 0 on the stack if both arguments are zero.
not num1 not (12 5) 1_or_0
returns a 0 if num1 is non-zero; returns a 1 if num1 is zero.
eq num1 num2 eq (12 15) 1_or_0
puts a 1 on the stack if num1 equals num2, otherwise a 0 (zero) is put on the stack.
ifelse s1 s2 v1 v2 ifelse (12 22) s1_or_s2
leaves the value s1 on the stack if v1 ≤ v2, or leaves s2 on the stack if v1 >v2. The value of s1 and s2 is usually the biased number of a subroutine; see section 2.3.

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.

Initial publication of 6 September 2016 document. See Appendix D Changes From CFF 1.0.

Partilhar via