Grammar for OpenType font files This table contains a compact representation of a PostScript Type 1, or CIDFont and is structured according to Adobe Technical Note #5176: “The Compact Font Format Specification,” and Adobe Technical Note #5177: “Type 2 Charstring Format.” Existing TrueType fonts use a glyph index to specify and access glyphs within a font, e.g. to index the loca table and thereby access glyph data in the glyf table. This concept is retained in OpenType™ PostScript fonts except that glyph data is accessed through the CharStrings INDEX of the CFF table The DSIG table contains the digital signature of the OpenType™ font. Signature formats are widely documented and rely on a key pair architecture. Software developers, or publishers posting material on the Internet, create signatures using a private key. Operating systems or applications authenticate the signature using a public key. The W3C and major software and operating system developers have specified security standards that describe signature formats, specify secure collections of web objects, and recommend authentication architecture. OpenType fonts with signatures will support these standards. OpenType fonts offer many security features: Operating systems and browsing applications can identify the source and integrity of font files before using them, Font developers can specify embedding restrictions in OpenType fonts, and these restrictions cannot be altered in a font signed by the developer. The enforcement of signatures is an administrative policy, enabled by the operating system. Windows will soon require installed software components, including fonts, to be signed. Internet browsers will also give users and administrators the ability to screen out unsigned objects obtained on-line, including web pages, fonts, graphics, and software components. Anyone can obtain identity certificates and encryption keys from a certifying agency, such as Verisign or GTE's Cybertrust, free or at a very low cost Version number of the DSIG table (0x00000001) Number of signatures in the table Permission flags Permission bit 0 allows a party signing the font to prevent any other parties from also signing the font (counter-signatures). If this bit is set to zero (0) the font may have a signature applied over the existing digital signature(s). A party who wants to ensure that their signature is the last signature can set this bit Format of the signature The format identifier specifies both the format of the signature object, as well as the hashing algorithm used to create and authenticate the signature. Currently only one format is defined, but at least one other format will soon be defined to handle subsetting scenarios. Format 1 supports PKCS#7 signatures with X.509 certificates and counter-signatures, as these signatures have been standardized for use by the W3C with the participation of numerous software developers. For more information about PKCS#7 signatures, see ftp://ftp.rsa.com/pub/pkcs/ascii/pkcs-7.asc For more information about counter-signatures, see ftp://ftp.rsa.com/pub/pkcs/ascii/pkcs-9.asc Format 1: For whole fonts, with either TrueType outlines and/or CFF data PKCS#7 or PKCS#9. The signed content digest is created as follows: If there is an existing DSIG table in the font, Remove DSIG table from font. Remove DSIG table entry from sfnt Table Directory. Adjust table offsets as necessary. Zero out the file checksum in the head table. Add the usFlag (reserved, set at 1 for now) to the stream of bytes Hash the full stream of bytes using a secure one-way hash (such as MD5) to create the content digest. Create the PKCS#7 signature block using the content digest. Create a new DSIG table containing the signature block. Add the DSIG table to the font, adjusting table offsets as necessary. Add a DSIG table entry to the sfnt Table Directory. Recalculate the checksum in the head table. Prior to signing a font file, ensure that all the following attributes are true. The magic number in the head table is correct. Given the number of tables value in the offset table, the other values in the offset table are consistent. The tags of the tables are ordered alphabetically and there are no duplicate tags. The offset of each table is a multiple of 4. (That is, tables are long word aligned.) The first actual table in the file comes immediately after the directory of tables. If the tables are sorted by offset, then for all tables i (where index 0 means the the table with the smallest offset), Offset[i] + Length[i] <= Offset[i+1] and Offset[i] + Length[i] >= Offset[i+1] - 3. In other words, the tables do not overlap, and there are at most 3 bytes of padding between tables. The pad bytes between tables are all zeros. The offset of the last table in the file plus its length is not greater than the size of the file. The checksums of all tables are correct. The head table's checkSumAdjustment field is correct Length of signature in bytes Reserved for later use; 0 for now Reserved for later use; 0 for now Length (in bytes) of the PKCS#7 packet in pbSignature This table gives global information about the font. The bounding box values should be computed using only glyphs that have contours. Glyphs with no contours should be ignored for the purposes of these calculations 0x00010000 for version 1.0 Set by font manufacturer To compute: set it to 0, sum the entire font as ULONG, then store 0xB1B0AFBA - sum Set to 0x5F0F3CF5 Valid range is from 16 to 16384. This value should be a power of 2 for fonts that have TrueType outlines Number of seconds since 12:00 midnight, January 1, 1904. 64-bit integer Number of seconds since 12:00 midnight, January 1, 1904. 64-bit integer For all glyph bounding boxes For all glyph bounding boxes For all glyph bounding boxes For all glyph bounding boxes Smallest readable size in pixels Deprecated (Set to 2) Typographic ascent. (Distance from baseline of highest ascender) Typographic descent. (Distance from baseline of lowest descender) Typographic line gap. Negative LineGap values are treated as zero in Windows 3.1, System 6, and System 7 Maximum advance width value in 'hmtx' table Minimum left sidebearing value in 'hmtx' table Minimum right sidebearing value; calculated as Min(aw - lsb - (xMax - xMin)) Max(lsb + (xMax - xMin)) Used to calculate the slope of the cursor (rise/run); 1 for vertical 0 for vertical The amount by which a slanted highlight on a glyph needs to be shifted to produce the best appearance. Set to 0 for non-slanted fonts set to 0 0 for current format Number of hMetric entries in 'hmtx' table 0x00005000 for version 0.5 (Note the difference in the representation of a non-zero fractional part, in Fixed numbers.) The number of glyphs in the font 0x00005000 for version 0.5 (Note the difference in the representation of a non-zero fractional part, in Fixed numbers.) Maximum points in a non-composite glyph Maximum contours in a non-composite glyph Maximum points in a composite glyph Maximum contours in a composite glyph should be set to 2 in most cases Maximum points used in Z0 Number of Storage Area locations Number of FDEFs Number of IDEFs Maximum stack depth Maximum byte count for glyph instructions Maximum number of components referenced at “top level” for any composite glyph Maximum levels of recursion; 1 for simple components Format selector (=0) Number of name records Offset to start of string storage (from start of table) Format selector (=0) Number of name records Language-tag string length (in bytes) Language-tag string offset from start of storage area (in bytes) OS/2 table version number The version number for this OS/2 table. The version number allows for identification of the precise contents and layout for the OS/2 table. The version number for this layout is four (4). Versions zero (0, TrueType rev 1.5), one (1, TrueType rev 1.66), two (2, OpenType rev 1.2) and three (3, OpenType rev 1.4) have been used previously. Average weighted escapement The Average Character Width parameter specifies the arithmetic average of the escapement (width) of all non-zero width glyphs in the font. The value for xAvgCharWidth is calculated by obtaining the arithmetic average of the width of all non-zero width glyphs in the font. Furthermore, it is strongly recommended that implementers do not rely on this value for computing layout for lines of text. Especially, for cases where complex scripts are used. Weight class Indicates the visual weight (degree of blackness or thickness of strokes) of the characters in the font. Width class Indicates a relative change from the normal aspect ratio (width to height ratio) as specified by a font designer for the glyphs in a font. Although every character in a font may have a different numeric aspect ratio, each character in a font of normal width has a relative aspect ratio of one. When a new type style is created of a different width class (either by a font designer or by some automated means) the relative aspect ratio of the characters in the new font is some percentage greater or less than those same characters in the normal font -- it is this difference that this parameter specifies. Type flags Indicates font embedding licensing rights for the font. Embeddable fonts may be stored in a document. When a document with embedded fonts is opened on a system that does not have the font installed (the remote system), the embedded font may be loaded for temporary (and in some cases, permanent) use on that system by an embedding-aware application. Embedding licensing rights are granted by the vendor of the font. The OpenType Font Embedding DLL Specification and DLL release notes describe the APIs used to implement support for OpenType font embedding and loading. Applications that implement support for font embedding, either through use of the Font Embedding DLL or through other means, must not embed fonts which are not licensed to permit embedding. Further, applications loading embedded fonts for temporary use (see Preview & Print and Editable embedding below) must delete the fonts when the document containing the embedded font is closed. This version of the OS/2 table makes bits 0 - 3 a set of exclusive bits. In other words, at most one bit in this range may be set at a time. The purpose is to remove misunderstandings caused by previous behavior of using the least restrictive of the bits that are set. Installable Embedding: No fsType bit is set. Thus fsType is zero. Fonts with this setting indicate that they may be embedded and permanently installed on the remote system by an application. The user of the remote system acquires the identical rights, obligations and licenses for that font as the original purchaser of the font, and is subject to the same end-user license agreement, copyright, design patent, and/or trademark as was the original purchaser Subscript horizontal font size The recommended horizontal size in font design units for subscripts for this font. If a font has two recommended sizes for subscripts, e.g., numerics and other, the numeric sizes should be stressed. This size field maps to the em square size of the font being used for a subscript. The horizontal font size specifies a font designer's recommended horizontal font size for subscript characters associated with this font. If a font does not include all of the required subscript characters for an application, and the application can substitute characters by scaling the character of a font or by substituting characters from another font, this parameter specifies the recommended em square for those subscript characters. For example, if the em square for a font is 2048 and ySubScriptXSize is set to 205, then the horizontal size for a simulated subscript character would be 1/10th the size of the normal character. Subscript vertical font size. The recommended vertical size in font design units for subscripts for this font. If a font has two recommended sizes for subscripts, e.g. numerics and other, the numeric sizes should be stressed. This size field maps to the emHeight of the font being used for a subscript. The horizontal font size specifies a font designer's recommendation for horizontal font size of subscript characters associated with this font. If a font does not include all of the required subscript characters for an application, and the application can substitute characters by scaling the characters in a font or by substituting characters from another font, this parameter specifies the recommended horizontal EmInc for those subscript characters. For example, if the em square for a font is 2048 and ySubScriptYSize is set to 205, then the vertical size for a simulated subscript character would be 1/10th the size of the normal character. Subscript x offset. The recommended horizontal offset in font design untis for subscripts for this font. The Subscript X Offset parameter specifies a font designer's recommended horizontal offset -- from the character origin of the font to the character origin of the subscript's character -- for subscript characters associated with this font. If a font does not include all of the required subscript characters for an application, and the application can substitute characters, this parameter specifies the recommended horizontal position from the character escapement point of the last character before the first subscript character. For upright characters, this value is usually zero; however, if the characters of a font have an incline (italic characters) the reference point for subscript characters is usually adjusted to compensate for the angle of incline. Subscript y offset. The recommended vertical offset in font design units from the baseline for subscripts for this font. The Subscript Y Offset parameter specifies a font designer's recommended vertical offset from the character baseline to the character baseline for subscript characters associated with this font. Values are expressed as a positive offset below the character baseline. If a font does not include all of the required subscript for an application, this parameter specifies the recommended vertical distance below the character baseline for those subscript characters. Superscript horizontal font size. The recommended horizontal size in font design units for superscripts for this font. If a font has two recommended sizes for subscripts, e.g., numerics and other, the numeric sizes should be stressed. This size field maps to the em square size of the font being used for a subscript. The horizontal font size specifies a font designer's recommended horizontal font size for superscript characters associated with this font. If a font does not include all of the required superscript characters for an application, and the application can substitute characters by scaling the character of a font or by substituting characters from another font, this parameter specifies the recommended em square for those superscript characters. For example, if the em square for a font is 2048 and ySuperScriptXSize is set to 205, then the horizontal size for a simulated superscript character would be 1/10th the size of the normal character. Superscript vertical font size. The recommended vertical size in font design units for superscripts for this font. If a font has two recommended sizes for subscripts, e.g., numerics and other, the numeric sizes should be stressed. This size field maps to the emHeight of the font being used for a subscript. The vertical font size specifies a font designer's recommended vertical font size for superscript characters associated with this font. If a font does not include all of the required superscript characters for an application, and the application can substitute characters by scaling the character of a font or by substituting characters from another font, this parameter specifies the recommended EmHeight for those superscript characters. For example, if the em square for a font is 2048 and ySuperScriptYSize is set to 205, then the vertical size for a simulated superscript character would be 1/10th the size of the normal character. Superscript x offset. The recommended horizontal offset in font design units for superscripts for this font. The Superscript X Offset parameter specifies a font designer's recommended horizontal offset -- from the character origin to the superscript character's origin for the superscript characters associated with this font. If a font does not include all of the required superscript characters for an application, this parameter specifies the recommended horizontal position from the escapement point of the character before the first superscript character. For upright characters, this value is usually zero; however, if the characters of a font have an incline (italic characters) the reference point for superscript characters is usually adjusted to compensate for the angle of incline. Superscript y offset. The recommended vertical offset in font design units from the baseline for superscripts for this font. The Superscript Y Offset parameter specifies a font designer's recommended vertical offset -- from the character baseline to the superscript character's baseline associated with this font. Values for this parameter are expressed as a positive offset above the character baseline. If a font does not include all of the required superscript characters for an application, this parameter specifies the recommended vertical distance above the character baseline for those superscript characters. Strikeout size. Width of the strikeout stroke in font design units. This field should normally be the width of the em dash for the current font. If the size is one, the strikeout line will be the line represented by the strikeout position field. If the value is two, the strikeout line will be the line represented by the strikeout position and the line immediately above the strikeout position. For a Roman font with a 2048 em square, 102 is suggested. Strikeout position. The position of the top of the strikeout stroke relative to the baseline in font design units. Positive values represent distances above the baseline, while negative values represent distances below the baseline. A value of zero falls directly on the baseline, while a value of one falls one pel above the baseline. The value of strikeout position should not interfere with the recognition of standard characters, and therefore should not line up with crossbars in the font. For a Roman font with a 2048 em square, 460 is suggested. Font-family class and subclass. This parameter is a classification of font-family design. The font class and font subclass are registered values assigned by IBM to each font family. This parameter is intended for use in selecting an alternate font when the requested font is not available. The font class is the most general and the font subclass is the most specific. The high byte of this field contains the family class, while the low byte contains the family subclass. Unicode Character Range This field is used to specify the Unicode blocks or ranges encompassed by the font file in the 'cmap' subtables for platform 3, encoding ID 1 (Microsoft platform, Unicode) and platform 3, encoding ID 10 (Microsoft platform, UCS-4). If the bit is set (1) then the Unicode range is considered functional. If the bit is clear (0) then the range is not considered functional. Each of the bits is treated as an independent flag and the bits can be set in any combination. The determination of “functional” is left up to the font designer, although character set selection should attempt to be functional by ranges if at all possible. All reserved fields must be zero. Each long is in Big-Endian form. See ISO/IEC 10646 or the most recent version of the Unicode Standard for the list of Unicode ranges and characters. Font Vendor Identification The four character identifier for the vendor of the given type face. This is not the royalty owner of the original artwork. This is the company responsible for the marketing and distribution of the typeface that is being classified. It is reasonable to assume that there will be 6 vendors of ITC Zapf Dingbats for use on desktop platforms in the near future (if not already). It is also likely that the vendors will have other inherent benefits in their fonts (more kern pairs, unregularized data, hand hinted, etc.). This identifier will allow for the correct vendor's type to be used over another, possibly inferior, font file. The Vendor ID value is not required. Microsoft has assigned values for some font suppliers as listed below. Uppercase vendor ID's are reserved by Microsoft. Other suppliers can choose their own mixed case or lowercase ID's, or leave the field blank. Font selection flags. Contains information concerning the nature of the font patterns The minimum Unicode index (character code) in this font, according to the cmap subtable for platform ID 3 and platform- specific encoding ID 0 or 1. For most fonts supporting Win-ANSI or other character sets, this value would be 0x0020. This field cannot represent supplementary character values (codepoints greater than 0xFFFF). Fonts that support supplementary characters should set the value in this field to 0xFFFF if the minimum index value is a supplementary character. The maximum Unicode index (character code) in this font, according to the cmap subtable for platform ID 3 and encoding ID 0 or 1. This value depends on which character sets the font supports. This field cannot represent supplementary character values (codepoints greater than 0xFFFF). Fonts that support supplementary characters should set the value in this field to 0xFFFF. The typographic ascender for this font. Remember that this is not the same as the Ascender value in the 'hhea' table, which Apple defines in a far different manner. One good source for sTypoAscender in Latin based fonts is the Ascender value from an AFM file. For CJK fonts see below. The suggested usage for sTypoAscender is that it be used in conjunction with unitsPerEm to compute a typographically correct default line spacing. The goal is to free applications from Macintosh or Windows-specific metrics which are constrained by backward compatibility requirements. These new metrics, when combined with the character design widths, will allow applications to lay out documents in a typographically correct and portable fashion. These metrics will be exposed through Windows APIs. Macintosh applications will need to access the 'sfnt' resource and parse it to extract this data from the “OS/2” table. For CJK (Chinese, Japanese, and Korean) fonts that are intended to be used for vertical writing (in addition to horizontal writing), the required value for sTypoAscender is that which describes the top of the of the ideographic em-box. For example, if the ideographic em-box of the font extends from coordinates 0,-120 to 1000,880 (that is, a 1000x1000 box set 120 design units below the Latin baseline), then the value of sTypoAscender must be set to 880. Failing to adhere to these requirements will result in incorrect vertical layout. The typographic descender for this font. Remember that this is not the same as the Descender value in the 'hhea' table, which Apple defines in a far different manner. One good source for sTypoDescender in Latin based fonts is the Descender value from an AFM file. For CJK fonts see below. The suggested usage for sTypoDescender is that it be used in conjunction with unitsPerEm to compute a typographically correct default line spacing. The goal is to free applications from Macintosh or Windows-specific metrics which are constrained by backward compatability requirements. These new metrics, when combined with the character design widths, will allow applications to lay out documents in a typographically correct and portable fashion. These metrics will be exposed through Windows APIs. Macintosh applications will need to access the 'sfnt' resource and parse it to extract this data from the “OS/2” table (unless Apple exposes the 'OS/2' table through a new API). For CJK (Chinese, Japanese, and Korean) fonts that are intended to be used for vertical writing (in addition to horizontal writing), the required value for sTypoDescender is that which describes the bottom of the of the ideographic em-box. For example, if the ideographic em-box of the font extends from coordinates 0,-120 to 1000,880 (that is, a 1000x1000 box set 120 design units below the Latin baseline), then the value of sTypoDescender must be set to -120. Failing to adhere to these requirements will result in incorrect vertical layout. The typographic line gap for this font. Remember that this is not the same as the LineGap value in the 'hhea' table, which Apple defines in a far different manner. The suggested usage for usTypoLineGap is that it be used in conjunction with unitsPerEm to compute a typographically correct default line spacing. Typical values average 7-10% of units per em. The goal is to free applications from Macintosh or Windows-specific metrics which are constrained by backward compatability requirements (see chapter, “Recommendations for OpenType Fonts”). These new metrics, when combined with the character design widths, will allow applications to lay out documents in a typographically correct and portable fashion. These metrics will be exposed through Windows APIs. Macintosh applications will need to access the 'sfnt' resource and parse it to extract this data from the “OS/2” table (unless Apple exposes the 'OS/2' table through a new API) The ascender metric for Windows. This, too, is distinct from Apple's Ascender value and from the usTypoAscender values. usWinAscent is computed as the yMax for all characters in the Windows ANSI character set. usWinAscent is used to compute the Windows font height and default line spacing. For platform 3 encoding 0 fonts, it is the same as yMax. Windows will clip the bitmap of any portion of a glyph that appears above this value. Some applications use this value to determine default line spacing. This is strongly discouraged. The typographic ascender, descender and line gap fields in conjunction with unitsPerEm should be used for this purpose. Developers should set this field keeping the above factors in mind. If any clipping is unacceptable, then the value should be set to yMax. However, if a developer desires to provide appropriate default line spacing using this field, for those applications that continue to use this field for doing so (against OpenType recommendations), then the value should be set appropriately. In such a case, it may result in some glyph bitmaps being clipped. The descender metric for Windows. This, too, is distinct from Apple's Descender value and from the usTypoDescender values. usWinDescent is computed as the -yMin for all characters in the Windows ANSI character set. usWinDescent is used to compute the Windows font height and default line spacing. For platform 3 encoding 0 fonts, it is the same as -yMin. Windows will clip the bitmap of any portion of a glyph that appears below this value. Some applications use this value to determine default line spacing. This is strongly discouraged. The typographic ascender, descender and line gap fields in conjunction with unitsPerEm should be used for this purpose. Developers should set this field keeping the above factors in mind. If any clipping is unacceptable, then the value should be set to yMin. However, if a developer desires to provide appropriate default line spacing using this field, for those applications that continue to use this field for doing so (against OpenType recommendations), then the value should be set appropriately. In such a case, it may result in some glyph bitmaps being clipped. Code Page Character Range This field is used to specify the code pages encompassed by the font file in the 'cmap' subtable for platform 3, encoding ID 1 (Microsoft platform). If the font file is encoding ID 0, then the Symbol Character Set bit should be set. If the bit is set (1) then the code page is considered functional. If the bit is clear (0) then the code page is not considered functional. Each of the bits is treated as an independent flag and the bits can be set in any combination. The determination of “functional” is left up to the font designer, although character set selection should attempt to be functional by code pages if at all possible. Symbol character sets have a special meaning. If the symbol bit (31) is set, and the font file contains a 'cmap' subtable for platform of 3 and encoding ID of 1, then all of the characters in the Unicode range 0xF000 - 0xF0FF (inclusive) will be used to enumerate the symbol character set. If the bit is not set, any characters present in that range will not be enumerated as a symbol character set. This metric specifies the distance between the baseline and the approximate height of non-ascending lowercase letters measured in FUnits. This value would normally be specified by a type designer but in situations where that is not possible, for example when a legacy font is being converted, the value may be set equal to the top of the unscaled and unhinted glyph bounding box of the glyph encoded at U+0078 (LATIN SMALL LETTER X). If no glyph is encoded in this position the field should be set to 0. This metric, if specified, can be used in font substitution: the xHeight value of one font can be scaled to approximate the apparent size of another. This metric specifies the distance between the baseline and the approximate height of uppercase letters measured in FUnits. This value would normally be specified by a type designer but in situations where that is not possible, for example when a legacy font is being converted, the value may be set equal to the top of the unscaled and unhinted glyph bounding box of the glyph encoded at U+0048 (LATIN CAPITAL LETTER H). If no glyph is encoded in this position the field should be set to 0. This metric, if specified, can be used in systems that specify type size by capital height measured in millimeters. It can also be used as an alignment metric; the top of a drop capital, for instance, can be aligned to the sCapHeight metric of the first line of text. Whenever a request is made for a character that is not in the font, Windows provides this default character. If the value of this field is zero, glyph ID 0 is to be used for the default character otherwise this is the Unicode encoding of the glyph that Windows uses as the default character. This field cannot represent supplementary character values (codepoints greater than 0xFFFF), and so applications are strongly discouraged from using this field. This is the Unicode encoding of the glyph that Windows uses as the break character. The break character is used to separate words and justify text. Most fonts specify 'space' as the break character. This field cannot represent supplementary character values (codepoints greater than 0xFFFF) , and so applications are strongly discouraged from using this field. The maximum length of a target glyph context for any feature in this font. For example, a font which has only a pair kerning feature should set this field to 2. If the font also has a ligature feature in which the glyph sequence 'f f i' is substituted by the ligature 'ffi', then this field should be set to 3. This field could be useful to sophisticated line-breaking engines in determining how far they should look ahead to test whether something could change that effects the line breaking. For chaining contextual lookups, the length of the string (covered glyph) + (input sequence) + (lookahead sequence) should be considered. This TrueType-based font file contains exactly the 258 glyphs in the standard Macintosh TrueType font file (see The WGL4.0 Character Set chapter for a list of the Macintosh glyphs). As a result, the glyph names are taken from the system with no storage required by the font Italic angle in counter-clockwise degrees from the vertical. Zero for upright text, negative for text that leans to the right (forward) This is the suggested distance of the top of the underline from the baseline (negative values indicate below baseline). The PostScript definition of this FontInfo dictionary key (the y coordinate of the center of the stroke) is not used for historical reasons. The value of the PostScript key may be calculated by subtracting half the underlineThickness from the value of this field Suggested values for the underline thickness Set to 0 if the font is proportionally spaced, non-zero if the font is not proportionally spaced (i.e. monospaced) Minimum memory usage when an OpenType font is downloaded Maximum memory usage when an OpenType font is downloaded Minimum memory usage when an OpenType font is downloaded as a Type 1 font Maximum memory usage when an OpenType font is downloaded as a Type 1 font This is the version required by TrueType-based fonts to be used on Windows Number of glyphs (this should be the same as numGlyphs in 'maxp' table) This version of the 'post' table has been deprecated as of OpenType Specification v1.3. This version provides a space saving table for TrueType-based fonts which contain a pure subset of, or a simple reordering of, the standard Macintosh glyph set Number of glyphs Difference between graphic index and standard order of glyph This version is used by OpenType fonts with TrueType or CFF data. The version makes it possible to create a special font that is not burdened with a large 'post' table set of glyph names. This version specifies that no PostScript name information is provided for the glyphs in this font file. The printing behavior of this version on PostScript printers is unspecified, except that it should not result in a fatal or unrecoverable error. Some drivers may print nothing, other drivers may attempt to print using a default naming scheme. Windows makes use of the italic angle value in the 'post' table but does not actually require any glyph names to be stored as Pascal strings This table contains a list of values that can be referenced by instructions. They can be used, among other things, to control characteristics for different glyphs. This table is similar to the CVT Program, except that it is only run once, when the font is first used. It is used only for FDEFs and IDEFs. Thus the CVT Program need not contain function definitions. However, the CVT Program may redefine existing FDEFs or IDEFs. This table is optional. Upper limit of range, in PPEM Flags describing desired rasterizer behavior This table contains information that describes the glyphs in the font in the TrueType outline format. Information regarding the rasterizer (scaler) refers to the TrueType rasterizer If the number of contours is greater than or equal to zero, this is a single glyph; if negative, this is a composite glyph If the number of contours is greater than or equal to zero, this is a single glyph; if negative, this is a composite glyph If the number of contours is greater than or equal to zero, this is a single glyph; if negative, this is a composite glyph If the number of contours is greater than or equal to zero, this is a single glyph; if negative, this is a composite glyph If the number of contours is greater than or equal to zero, this is a single glyph; if negative, this is a composite glyph If the number of contours is greater than or equal to zero, this is a single glyph; if negative, this is a composite glyph Array of last points of each contour; n is the number of contours Total number of bytes for instructions Array of instructions for each glyph Array of flags for each coordinate in outline If the number of contours is greater than or equal to zero, this is a single glyph; if negative, this is a composite glyph Format of the subtable. Only formats 0 and 2 have been defined. Formats 1 and 3 through 255 are reserved for future use Reserved. This should be set to zero. If this bit is set to 1 the value in this table should replace the value currently being accumulated If set to 1, kerning is perpendicular to the flow of the text. If the text is normally written horizontally, kerning will be done in the up and down directions. If kerning values are positive, the text will be kerned upwards; if they are negative, the text will be kerned downwards. If the text is normally written vertically, kerning will be done in the left and right directions. If kerning values are positive, the text will be kerned to the right; if they are negative, the text will be kerned to the left. The value 0x8000 in the kerning data resets the cross-stream kerning back to 0 If this bit is set to 1, the table has minimum values. If set to 0, the table has kerning values 1 if table has horizontal data, 0 if vertical Kern subtable version number Length of the subtable, in bytes (including this header) Format of the subtable. Only formats 0 and 2 have been defined. Formats 1 and 3 through 255 are reserved for future use This gives the number of kerning pairs in the table The largest power of two less than or equal to the value of nPairs, multiplied by the size in bytes of an entry in the table This is calculated as log2 of the largest power of two less than or equal to the value of nPairs. This value indicates how many iterations of the search loop will have to be made. (For example, in a list of eight items, there would have to be three iterations of the loop) The value of nPairs minus the largest power of two less than or equal to nPairs, and then multiplied by the size in bytes of an entry in the table The glyph index for the left-hand glyph in the kerning pair The glyph index for the right-hand glyph in the kerning pair The kerning value for the above pair, in FUnits. If this value is greater than zero, the characters will be moved apart. If this value is less than zero, the character will be moved closer together This subtable is a two-dimensional array of kerning values. The glyphs are mapped to classes, using a different mapping for left- and right-hand glyphs. This allows glyphs that have similar right- or left-side shapes to be handled together. Each similar right- or left-hand shape is said to be single class. Each row in the kerning array represents one left-hand glyph class, each column represents one right-hand glyph class, and each cell contains a kerning value. Row and column 0 always represent glyphs that do not kern and contain all zeros. The values in the right class table are stored pre-multiplied by the number of bytes in a single kerning value, and the values in the left class table are stored pre-multiplied by the number of bytes in one row. This eliminates needing to multiply the row and column values together to determine the location of the kerning value. The array can be indexed by doing the right- and left-hand class mappings, adding the class values to the address of the array, and fetching the kerning value to which the new address points Format of the subtable. Only formats 0 and 2 have been defined. Formats 1 and 3 through 255 are reserved for future use The indexToLoc table stores the offsets to the locations of the glyphs in the font, relative to the beginning of the glyphData table. In order to compute the length of the last glyph element, there is an extra entry after the last valid index. By definition, index zero points to the “missing character,” which is the character that appears if a character is not found in the font. The missing character is commonly represented by a blank box or a space. If the font does not contain an outline for the missing character, then the first and second offsets should have the same value. This also applies to any other characters without an outline, such as the space character. If a glyph has no outline, then loca[n] = loca [n+1]. In the particular case of the last glyph(s), loca[n] will be equal the length of the glyph data ('glyf') table. The offsets must be in ascending order with loca[n] <= loca[n+1]. Most routines will look at the 'maxp' table to determine the number of glyphs in the font, but the value in the 'loca' table must agree. There are two versions of this table, the short and the long. The version is specified in the indexToLocFormat entry in the 'head' table The Control Value Program consists of a set of TrueType instructions that will be executed whenever the font or point size or transformation matrix change and before each glyph is interpreted. Any instruction is legal in the CV Program but since no glyph is associated with it, instructions intended to move points within a particular glyph outline cannot be used in the CV Program. The name 'prep' is anachronistic (the table used to be known as the Pre Program table.) Set of instructions executed whenever point size or font or transformation change. n is the number of BYTE items that fit in the size of the table The hdmx table relates to OpenType™ fonts with TrueType outlines. The Horizontal Device Metrics table stores integer advance widths scaled to particular pixel sizes. This allows the font manager to build integer width tables without calling the scaler for each glyph. Typically this table contains only selected screen sizes. This table is sorted by pixel size. The checksum for this table applies to both subtables listed. Note that for non-square pixel grids, the character width (in pixels) will be used to determine which device record to use. For example, a 12 point character on a device with a resolution of 72x96 would be 12 pixels high and 16 pixels wide. The hdmx device record for 16 pixel characters would be used. If bit 4 of the flag field in the 'head' table is not set, then it is assumed that the font scales linearly; in this case an 'hdmx' table is not necessary and should not be built. If bit 4 of the flag field is set, then one or more glyphs in the font are assumed to scale nonlinearly. In this case, performance can be improved by including the 'hdmx' table with one or more important DeviceRecord's for important sizes Table version number (0) Number of device records Size of a device record, long aligned Pixel size for following widths (as ppem) Maximum width