OS/2 — OS/2 and Windows Metrics Table
The OS/2 table consists of a set of metrics and other data that are required in OpenType fonts.
OS/2 Table Formats
Six versions of the OS/2 table have been defined: versions 0 to 5. All versions are supported, but use of version 4 or later is strongly recommended.
Version 5
The format of version 5 is as follows:
| Type | Name | Comments |
|---|---|---|
| uint16 | version | 0x0005 |
| FWORD | xAvgCharWidth | |
| uint16 | usWeightClass | |
| uint16 | usWidthClass | |
| uint16 | fsType | |
| FWORD | ySubscriptXSize | |
| FWORD | ySubscriptYSize | |
| FWORD | ySubscriptXOffset | |
| FWORD | ySubscriptYOffset | |
| FWORD | ySuperscriptXSize | |
| FWORD | ySuperscriptYSize | |
| FWORD | ySuperscriptXOffset | |
| FWORD | ySuperscriptYOffset | |
| FWORD | yStrikeoutSize | |
| FWORD | yStrikeoutPosition | |
| int16 | sFamilyClass | |
| uint8 | panose[10] | |
| uint32 | ulUnicodeRange1 | Bits 0 – 31 |
| uint32 | ulUnicodeRange2 | Bits 32 – 63 |
| uint32 | ulUnicodeRange3 | Bits 64 – 95 |
| uint32 | ulUnicodeRange4 | Bits 96 – 127 |
| Tag | achVendID | |
| uint16 | fsSelection | |
| uint16 | usFirstCharIndex | |
| uint16 | usLastCharIndex | |
| FWORD | sTypoAscender | |
| FWORD | sTypoDescender | |
| FWORD | sTypoLineGap | |
| UFWORD | usWinAscent | |
| UFWORD | usWinDescent | |
| uint32 | ulCodePageRange1 | Bits 0 – 31 |
| uint32 | ulCodePageRange2 | Bits 32 – 63 |
| FWORD | sxHeight | |
| FWORD | sCapHeight | |
| uint16 | usDefaultChar | |
| uint16 | usBreakChar | |
| uint16 | usMaxContext | |
| uint16 | usLowerOpticalPointSize | |
| uint16 | usUpperOpticalPointSize |
Version 4
Version 4 was defined in OpenType 1.5. Version 4 has two fewer fields than version 5, and the same fields as in version 3. Although new fields were not added beyond those in version 3, the specification of certain fields was revised. The format of version 4 is as follows:
| Type | Name |
|---|---|
| uint16 | version |
| FWORD | xAvgCharWidth |
| uint16 | usWeightClass |
| uint16 | usWidthClass |
| uint16 | fsType |
| FWORD | ySubscriptXSize |
| FWORD | ySubscriptYSize |
| FWORD | ySubscriptXOffset |
| FWORD | ySubscriptYOffset |
| FWORD | ySuperscriptXSize |
| FWORD | ySuperscriptYSize |
| FWORD | ySuperscriptXOffset |
| FWORD | ySuperscriptYOffset |
| FWORD | yStrikeoutSize |
| FWORD | yStrikeoutPosition |
| int16 | sFamilyClass |
| uint8 | panose[10] |
| uint32 | ulUnicodeRange1 |
| uint32 | ulUnicodeRange2 |
| uint32 | ulUnicodeRange3 |
| uint32 | ulUnicodeRange4 |
| Tag | achVendID |
| uint16 | fsSelection |
| uint16 | usFirstCharIndex |
| uint16 | usLastCharIndex |
| FWORD | sTypoAscender |
| FWORD | sTypoDescender |
| FWORD | sTypoLineGap |
| UFWORD | usWinAscent |
| UFWORD | usWinDescent |
| uint32 | ulCodePageRange1 |
| uint32 | ulCodePageRange2 |
| FWORD | sxHeight |
| FWORD | sCapHeight |
| uint16 | usDefaultChar |
| uint16 | usBreakChar |
| uint16 | usMaxContext |
Version 3
Version 3 was defined in OpenType 1.4. Version 3 has the same fields as in version 4, and as in version 2. Although new fields were not added beyond those in version 2, the specification of certain fields was revised to reflect changes in Unicode 3.2. The format of version 3 is identical to the format for version 4, given above.
Version 2
Version 2 was defined in OpenType 1.1. Version 2 has the same fields as in version 3, and five additional fields beyond those in version 1. The format of version 2 is identical to the format for version 4, given above.
Version 1
Version 1 was defined in TrueType revision 1.66. Version 1 has five fewer fields than version 2, and two additional fields beyond those in version 0. The format of version 1 is as follows:
| Type | Name |
|---|---|
| uint16 | version |
| FWORD | xAvgCharWidth |
| uint16 | usWeightClass |
| uint16 | usWidthClass |
| uint16 | fsType |
| FWORD | ySubscriptXSize |
| FWORD | ySubscriptYSize |
| FWORD | ySubscriptXOffset |
| FWORD | ySubscriptYOffset |
| FWORD | ySuperscriptXSize |
| FWORD | ySuperscriptYSize |
| FWORD | ySuperscriptXOffset |
| FWORD | ySuperscriptYOffset |
| FWORD | yStrikeoutSize |
| FWORD | yStrikeoutPosition |
| int16 | sFamilyClass |
| uint8 | panose[10] |
| uint32 | ulUnicodeRange1 |
| uint32 | ulUnicodeRange2 |
| uint32 | ulUnicodeRange3 |
| uint32 | ulUnicodeRange4 |
| Tag | achVendID |
| uint16 | fsSelection |
| uint16 | usFirstCharIndex |
| uint16 | usLastCharIndex |
| FWORD | sTypoAscender |
| FWORD | sTypoDescender |
| FWORD | sTypoLineGap |
| UFWORD | usWinAscent |
| UFWORD | usWinDescent |
| uint32 | ulCodePageRange1 |
| uint32 | ulCodePageRange2 |
Version 0
Version 0 was defined in TrueType revision 1.5. The format of version 0 is as follows:
| Type | Name |
|---|---|
| uint16 | version |
| FWORD | xAvgCharWidth |
| uint16 | usWeightClass |
| uint16 | usWidthClass |
| uint16 | fsType |
| FWORD | ySubscriptXSize |
| FWORD | ySubscriptYSize |
| FWORD | ySubscriptXOffset |
| FWORD | ySubscriptYOffset |
| FWORD | ySuperscriptXSize |
| FWORD | ySuperscriptYSize |
| FWORD | ySuperscriptXOffset |
| FWORD | ySuperscriptYOffset |
| FWORD | yStrikeoutSize |
| FWORD | yStrikeoutPosition |
| int16 | sFamilyClass |
| uint8 | panose[10] |
| uint32 | ulUnicodeRange1 |
| uint32 | ulUnicodeRange2 |
| uint32 | ulUnicodeRange3 |
| uint32 | ulUnicodeRange4 |
| Tag | achVendID |
| uint16 | fsSelection |
| uint16 | usFirstCharIndex |
| uint16 | usLastCharIndex |
| FWORD | sTypoAscender |
| FWORD | sTypoDescender |
| FWORD | sTypoLineGap |
| UFWORD | usWinAscent |
| UFWORD | usWinDescent |
Note: Documentation for OS/2 version 0 in Apple’s TrueType Reference Manual stops at the usLastCharIndex field and does not include the last five fields of the table as it was defined by Microsoft. Some legacy TrueType fonts could have been built with a shortened version 0 OS/2 table. Applications should check the table length for a version 0 OS/2 table before reading these fields.
OS/2 Field Details
This section provides details covering all versions of the OS/2 table.
version
| Format: | uint16 |
| Units: | n/a |
| Title: | OS/2 table version number. |
| Description: | The version number for the OS/2 table: 0x0000 to 0x0005. |
| Comments: | The version number allows for identification of the precise contents and layout for the OS/2 table. |
xAvgCharWidth
| Format: | FWORD | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Units: | Font design units | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Title: | Average weighted escapement. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | The Average Character Width field specifies the arithmetic average of the escapement (width) of all non-zero width glyphs in the font. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comments: | The value for xAvgCharWidth is calculated by obtaining the arithmetic average of the width of all non-zero width glyphs in the font. 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. Note: Some fonts have xAvgCharWidth values that do not conform to this calculation. Fonts could have been originally created with a version 0 to version 2 OS/2 table using the legacy calculation described below, then later updated with a newer OS/2 table version but without changing the xAvgCharWidth value. In some CJK fonts, the xAvgCharWidth can be almost half the value that would be expected by the above calculation. Applications should not use xAvgCharWidth for determining actual glyph advance widths. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Version differences: | Versions 0 to 2: When first defined, the specification was biased toward Basic Latin characters, and it was thought that the xAvgCharWidth value could be used to estimate the average length of lines of text. The following formula for calculating xAvgCharWidth was provided: For characters given in the table below, sum the width of each character times the weight factor indicated, then divide the total by 1000. This method of calculating the value of this field was superseded with the introduction of version 3 of the OS/2 table and is deprecated.
|
usWeightClass
| Format: | uint16 | ||||||||||||||||||||||||||||||
| Title: | Weight class. | ||||||||||||||||||||||||||||||
| Description: | Indicates the visual weight (degree of blackness or thickness of strokes) of the characters in the font. Values from 1 to 1000 are valid. | ||||||||||||||||||||||||||||||
| Comments: | usWeightClass values use the same scale as the 'wght' axis that is used in the 'fvar' table of variable fonts and in the STAT table. While integer values from 1 to 1000 are supported, some legacy platforms could have limitations on supported values. The following are commonly used values:
|
usWidthClass
| Format: | uint16 | ||||||||||||||||||||||||||||||||||||||||
| Title: | Width class. | ||||||||||||||||||||||||||||||||||||||||
| Description: | 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. | ||||||||||||||||||||||||||||||||||||||||
| Comments: |
Although every glyph in a font can have a different numeric aspect ratio, each glyph in a font of normal width is considered to have 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 glyphs in the new font is some percentage greater or less than the corresponding glyphs in the normal font — it is this difference that this field specifies.
|
fsType
| Format: | uint16 | ||||||||||||||||||
| Title: | Type flags. | ||||||||||||||||||
| Description: |
Indicates font embedding licensing rights for the font. The interpretation of flags is as follows:
|
||||||||||||||||||
| Comments: |
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.
Applications that implement support for font embedding must not embed fonts which are not licensed to permit embedding. Also, when embedding a font into a document, applications must not modify the embedding permissions and restrictions indicated in this field. In addition, applications loading embedded fonts for temporary use (Preview & Print or Editable embedding) must delete the fonts when the document containing the embedded font is closed. Bits 0 to 3 (the embedding permissions sub-field) are mutually exclusive: fonts should never have more than one of these bits set. Note that, if two or more bits are set, some applications could assume the least-restrictive permission indicated. (See version differences for more discussion.) Caution: Font vendors are responsible to set these bits correctly to obtain the desired application behaviors. For Restricted License embedding to take effect, the Embedding permissions sub-field must have the value 2 (that is, only bit 1 is set). Note: Apple’s TrueType Reference Manual specifies bit 1 of the fsType field, and only bit 1, as having an assigned semantic. This originated from a pre-release draft specification for the OS/2 table. However, the final specification for version 0 of the OS/2 table defined bits 0 to 3. Also, some early font implementations mistakenly used the value 1 (bit 0 set), leading to problems of non-interoperability. For this reason, bit 0 was specified as reserved in the final specification for version 0. Bit 0 is permanently reserved, and its use is deprecated. |
||||||||||||||||||
| Version differences: | Versions 0 to 1: only bits 0 to 3 were assigned. Applications must ignore bits 4 to 15 when reading a version 0 or version 1 table.
Versions 0 to 2: The specification for versions 0 to 2 did not specify that bits 0 to 3 must be mutually exclusive. Rather, those specifications stated that, in the event that more than one of bits 0 to 3 are set in a given font, then the least-restrictive permission indicated take precedence. In particular, some fonts using a version 0 to version 2 OS/2 table have both bit 2 and bit 3 set with the intent to indicate both preview/print and edit permissions. Applications are permitted to use this behavior for fonts with a version 0 to version 2 OS/2 table. Versions 3 and later: The specification for version 3, added in OpenType 1.4, introduced the explicit requirement that bits 0 to 3 must be mutually exclusive. |
ySubscriptXSize
| Format: | FWORD |
| Units: | Font design units |
| Title: | Subscript horizontal font size. |
| Description: | The recommended horizontal size in font design units for subscripts for this font. Should be > 0. |
| Comments: | 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 size of the font being used for a subscript. The horizontal font size specifies a font designer’s recommended horizontal size of subscript glyphs associated with this font. If a font does not include all required subscript glyphs for an application, and the application can substitute glyphs by scaling the glyphs of a font or by substituting glyphs from another font, this field specifies the recommended nominal width for those subscript glyphs.
For example, if the em for a font is 2048 units and ySubScriptXSize is set to 205, then the horizontal size for a simulated subscript glyph would be 1/10th the size of the normal glyph. Note: This was implemented in the OS/2 platform as a signed value, even though only values > 0 would be expected. |
ySubscriptYSize
| Format: | FWORD |
| Units: | Font design units |
| Title: | Subscript vertical font size. |
| Description: | The recommended vertical size in font design units for subscripts for this font. Should be > 0. |
| Comments: | 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 size of the font being used for a subscript. The vertical font size specifies a font designer’s recommendation for vertical size of subscript glyphs associated with this font. If a font does not include all required subscript glyphs for an application, and the application can substitute glyphs by scaling the glyphs in a font or by substituting glyphs from another font, this field specifies the recommended nominal height for those subscript glyphs.
For example, if the em for a font is 2048 units and ySubScriptYSize is set to 205, then the vertical size for a simulated subscript glyph would be 1/10th the size of the normal glyph. Note: This was implemented in the OS/2 platform as a signed value, even though only values > 0 would be expected. |
ySubscriptXOffset
| Format: | FWORD |
| Units: | Font design units |
| Title: | Subscript x offset. |
| Description: | The recommended horizontal offset in font design units for subscripts for this font. |
| Comments: | The ySubscriptXOffset field specifies a font designer’s recommended horizontal offset — from the glyph origin to the glyph origin of the subscript’s glyph — for subscript glyphs associated with this font. If a font does not include all required subscript glyphs for an application, and the application can substitute glyphs, this field specifies the recommended horizontal position from the glyph escapement point of the last glyph before the first subscript glyph. For upright glyphs, this value is usually zero; however, if the glyphs of a font have an incline (italic or slant), the reference point for subscript glyphs is usually adjusted to compensate for the angle of incline. |
ySubscriptYOffset
| Format: | FWORD |
| Units: | Font design units |
| Title: | Subscript y offset. |
| Description: | The recommended vertical offset in font design units from the baseline for subscripts for this font. |
| Comments: | The ySubscriptYOffset field specifies a font designer’s recommended vertical offset from the glyph baseline to the glyph baseline for subscript glyphs associated with this font. Values are expressed as a positive offset below the glyph baseline. If a font does not include all required subscript glyphs for an application, this field specifies the recommended vertical distance below the glyph baseline for alternate subscript glyphs supplied by the application. |
ySuperscriptXSize
| Format: | FWORD |
| Units: | Font design units |
| Title: | Superscript horizontal font size. |
| Description: | The recommended horizontal size in font design units for superscripts for this font. Should be > 0. |
| Comments: | If a font has two recommended sizes for superscripts, e.g., numerics and other, the numeric sizes should be stressed. This size field maps to the em size of the font being used for a superscript. The horizontal font size specifies a font designer’s recommended horizontal size for superscript glyphs associated with this font. If a font does not include all required superscript glyphs for an application, and the application can substitute glyphs by scaling the glyphs of a font or by substituting glyphs from another font, this field specifies the recommended nominal width for those superscript glyphs.
For example, if the em for a font is 2048 units and ySuperScriptXSize is set to 205, then the horizontal size for a simulated superscript glyph would be 1/10th the size of the normal glyph. Note: This was implemented in the OS/2 platform as a signed value, even though only values > 0 would be expected. |
ySuperscriptYSize
| Format: | FWORD |
| Units: | Font design units |
| Title: | Superscript vertical font size. |
| Description: | The recommended vertical size in font design units for superscripts for this font. Should be > 0. |
| Comments: | If a font has two recommended sizes for superscripts, e.g., numerics and other, the numeric sizes should be stressed. This size field maps to the em size of the font being used for a superscript. The vertical font size specifies a font designer’s recommended vertical size for superscript glyphs associated with this font. If a font does not include all required superscript glyphs for an application, and the application can substitute glyphs by scaling the glyphs of a font or by substituting glyphs from another font, this field specifies the recommended nominal height for those superscript glyphs.
For example, if the em for a font is 2048 units and ySuperScriptYSize is set to 205, then the vertical size for a simulated superscript glyph would be 1/10th the size of the normal glyph. Note: This was implemented in the OS/2 platform as a signed value, even though only values > 0 would be expected. |
ySuperscriptXOffset
| Format: | FWORD |
| Units: | Font design units |
| Title: | Superscript x offset. |
| Description: | The recommended horizontal offset in font design units for superscripts for this font. |
| Comments: | The ySuperscriptXOffset field specifies a font designer’s recommended horizontal offset — from the glyph’s origin to the superscript glyph’s origin for the superscript glyphs associated with this font. If a font does not include all required superscript glyphs for an application, this field specifies the recommended horizontal position from the escapement point of the glyph before the first superscript glyph. For upright glyphs, this value is usually zero; however, if the glyphs of a font have an incline (italic or slant), the reference point for superscript glyphs is usually adjusted to compensate for the angle of incline. |
ySuperscriptYOffset
| Format: | FWORD |
| Units: | Font design units |
| Title: | Superscript y offset. |
| Description: | The recommended vertical offset in font design units from the baseline for superscripts for this font. |
| Comments: | The ySuperscriptYOffset field specifies a font designer’s recommended vertical offset — from the glyph’s baseline to the superscript glyph’s baseline associated with this font. Values for this field are expressed as a positive offset above the glyph baseline. If a font does not include all required superscript glyphs for an application, this field specifies the recommended vertical distance above the glyph baseline for alternate superscript glyphs supplied by the application. |
yStrikeoutSize
| Format: | FWORD |
| Units: | Font design units |
| Title: | Strikeout size. |
| Description: | Thickness of the strikeout stroke in font design units. Should be > 0. |
| Comments: | This field should normally be the thickness of the em dash for the current font, and should also match the underline thickness, which is specified in the 'post' table. Note: This was implemented in the OS/2 platform as a signed value, even though only values > 0 would be expected. |
yStrikeoutPosition
| Format: | FWORD |
| Units: | Font design units |
| Title: | Strikeout position. |
| Description: | The position of the top of the strikeout stroke relative to the baseline in font design units. |
| Comments: | Positive values represent distances above the baseline; negative values represent distances below the baseline. Aligning the strikeout position with the em dash is suggested. Note, however, that the strikeout position should not interfere with the recognition of standard characters, and therefore should not line up with crossbars in the font. |
sFamilyClass
| Format: | int16 |
| Title: | Font-family class and subclass. |
| Description: | This field provides a classification of font-family design. |
| Comments: | The family class and subclass are assigned to a font based on the family design. This field is intended for use in selecting an alternate font family when the requested font is not available. The class and subclass provide a two-level classification. The high byte of this field contains the family class, while the low byte contains the family subclass. The interpretation of subclass values depends on the class value. Registered class and subclass values were originally defined by IBM. For details on registered values, see IBM Font Family Classifications. |
panose
| Format: | uint8[10] | ||||||||||||||||||||||
| Title: | PANOSE classification number | ||||||||||||||||||||||
| International: | Additional specifications are required for PANOSE to classify non-Latin character sets. | ||||||||||||||||||||||
| Description: | This 10-byte array of numbers is used to describe the visual characteristics of a given typeface. These characteristics are then used to associate the font with other fonts of similar appearance having different names. The variables for each digit are listed below. | ||||||||||||||||||||||
| Comments: | The PANOSE definition contains ten bytes, each of which can have multiple possible values. The PANOSE values are fully described in the PANOSE Classification Metrics Guide. Note that the first byte is used for a high-level classification, “Family Kind”, and that the interpretation of the remaining bytes is contingent on the value of the first byte. For example, if the Family Kind value is 2 (Latin Text), then the next byte specifies “Serif Style”; but if the Family Kind value is 3 (Latin Hand Written), then the next byte specifies “Tool Kind”. Some applications might support only certain Family Kind values. The following table gives the interpretation for the panose array when the Family Kind is Latin Text:
Some applications can use the PANOSE values for font selection, to select a font matching certain parameters. For example, Proportion (for Family Kind = Latin Text) might be used to determine if a font is monospaced; or Serif Style might be used to determine if a font falls into generic serif or sans serif classes. Some applications will use Family Kind = 5 (Latin Symbol) to identify symbol fonts, which might affect font selection or fallback behaviors. There are no requirements for how applications should use the PANOSE values. In a variable font that uses OpenType Font Variation mechanisms, there is no way to represent different PANOSE values for different instances supported by the font. The PANOSE values can be set based on the default instance. |
||||||||||||||||||||||
| Version differences: | Early versions of this specification provided more details regarding PANOSE values. However, the external specification cited above is the normative source and should be referred to for such details. |
ulUnicodeRange*
ulUnicodeRange1 (bits 0 – 31)
ulUnicodeRange2 (bits 32 – 63)
ulUnicodeRange3 (bits 64 – 95)
ulUnicodeRange4 (bits 96 – 127)
| Format: | uint32[4] (128 bits total) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Title: | Unicode Character Range | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | This field is used to specify the Unicode blocks or ranges encompassed by the font file in 'cmap' subtables for platform 3, encoding ID 1 (Microsoft platform, Unicode BMP) and platform 3, encoding ID 10 (Microsoft platform, Unicode full repertoire). If a bit is set (1), then the Unicode ranges assigned to that bit are 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 uint32 is in Big-Endian form.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comments: | All available bits were exhausted as of Unicode 5.1. The bit assignments were last updated for OS/2 version 4 in OpenType 1.5. There are many additional ranges supported in the current version of Unicode that are not supported by these fields in the OS/2 table. See the 'dlng' and 'slng' tags in the 'meta' table for an alternate mechanism to declare what scripts or languages a font can support or is designed for. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Version differences: |
Different versions of the OS/2 table were created when different Unicode versions were current, and the initial specification for a given version defined fewer bit assignments than for later versions. Some applications might not support all assignments for fonts that have earlier OS/2 versions.
All of the bit assignments listed above are valid for any version of the OS/2 table, though OS/2 versions 1 and 2 were specified with some assignments that did not correspond to well-defined Unicode ranges and that conflict with later assignments — see the details below. If a font has a version 1 or version 2 OS/2 table with one of these bits set, the obsolete assignment could be the intended interpretation. Because these assignments do not correspond to well-defined ranges, however, the implied character coverage is unclear. Version 0: When version 0 was first specified, no bit assignments were defined. Some applications could ignore these fields in a version 0 OS/2 table. Version 1: Version 1 was first specified concurrent with Unicode 1.1, and bit assignments were defined for bits 0 to 69 only. With fonts that have a version 1 table, some applications might recognize only bits 0 to 69. Also, version 1 was specified with some bit assignments that did not correspond to a well-defined Unicode range:
In addition, versions 1 and 2 were defined with bit 53 specified as “CJK Miscellaneous”, which also does not correspond to any well-defined Unicode range. This assignment was discontinued as of version 3. Version 2: Version 2 was defined in OpenType 1.1, which was concurrent with Unicode 2.1. At that time, bit assignments were defined for bits 0 to 69 only. Bit assignments for version 2 were updated in OpenType 1.3, adding assignments for bits 70 to 83 corresponding to new blocks assigned in Unicode 2.0 and Unicode 3.0. With fonts that have a version 2 table, some applications might recognize only those bits assigned in OpenType 1.2 or OpenType 1.3. Also, the specification for version 2 continued to use a problematic assignment for bit 53 — see details for version 1. This assignment was discontinued as of version 3. Version 3: Version 3 was defined in OpenType 1.4 with assignments for bits 84 to 92 corresponding to additional ranges in Unicode 3.2. In addition, some already-assigned bits were extended to cover additional Unicode ranges for related characters; see details in the table above. Version 4: Version 4 was defined in OpenType 1.5 with assignments for bit 58 and bits 93 to 122 corresponding to additional ranges in Unicode 5.1. Also, bits 8, 12, 14, 27 and 53 were re-assigned (see version 1 for previous assignments). In addition, some already-assigned bits were extended to cover additional Unicode ranges for related characters; see details in the table above. |
achVendID
| Format: | Tag |
| Title: | Font Vendor Identification |
| Description: | The four character identifier for the vendor of the given type face. |
| Comments: | 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. For example, there can be multiple vendors of ITC Zapf Dingbats, with some vendors providing differentiating 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.
A registry of vendor IDs is maintained by Microsoft. Registered IDs must be unique to a single vendor. Non-registered IDs may also be used, but are discouraged: vendors are strongly encouraged to register an ID to ensure that there are no conflicts between different vendors in use of a given ID, and that customers are able to find vendor contact information for a given font. This field can also be left blank (set to null, or a tag comprised of four space characters). All vendor IDs use the Tag data type, which is equivalent to a four-character string composed of a limited set of ASCII characters. For details regarding the Tag data type, see Data Types. By convention, only registered tags should be comprised of only uppercase letters (or space). For a list of registered Vendor IDs, or for details on registering a vendor ID or updating vendor information, see Registered typography vendors. |
fsSelection
| Format: | uint16 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Title: | Font selection flags. | ||||||||||||||||||||||||||||||||||||||||||||||||
| Description: |
Contains information concerning the nature of the font patterns, as follows:
|
||||||||||||||||||||||||||||||||||||||||||||||||
| Comments: |
All undefined bits must be zero.
The fsSelection field was originally created for compatibility with the OS/2 platform. Some style description bits, such as bit 0, are used by modern applications, while other style description bits are not. Bit 0: The setting of bits 0 must match the setting of bit 1 in the macStyle field of the 'head' table. Bits 1 – 4: Bits 1 – 4 are rarely used bits that indicate the font is primarily a decorative or special purpose font. Bit 5: The setting of bit 5 must match the settings of bit 0 in the macStyle field of the 'head' table. Bit 6: Bit 6 is not used in widely used in modern applications. If bit 6 is set, then bits 0 and 5 must be clear, else the behavior is undefined. Note that, if both bit 0 and bit 5 are clear, that does not give any indication as to whether or not bit 6 will be clear. For example, Arial Light is not the regular style of Arial and would have all bits cleared. In extended font families, bit 6 does not need to be set for fonts other than the regular style that, nonetheless, use "Regular" for name ID 2. (See Name IDs for more information.) Bit 7: Bit 7 was defined in version 4 and is used in many modern applications. For new fonts, vendors are encouraged to use a version 4 or later OS/2 table and to have bit 7 set. If a font was created with an earlier version of the OS/2 table and is updated to the current version of the OS/2 table, then setting bit 7 could create potential for reflow of existing documents which use the fonts. To minimize such risk, the bit would be set only if using the OS/2.usWin* metrics for line height would yield significantly inferior results than using the OS/2.sTypo* values. Bit 8: If bit 8 is set, then 'name' table strings for family and subfamily are provided that are consistent with a weight/width/slope (WWS) family model without requiring the use of name IDs 21 or 22. Bit 8 and name IDs 21 and 22 were introduced for use by applications that assume a WWS family model, given that there exist fonts with style variants that do not fit into one of the three attributes, weight, width or slope. Many typographic families include faces that differ only in one or more of these three attributes. In such cases, name IDs 1 and 2 or IDs 16 and 17 will not present challenges for software that assumes a WWS model. But some typographic families include faces that differ in some other attributes. For example, a family might include variations for “handwriting”, “caption”, “display”, “optical size”, etc. In such cases, a font could incorporate that attribute into a typographic subfamily name (ID 17 string), whereas applications that assume a WWS model would require that attribute to be incorporated into a family name (ID 1 or ID 16). IF a face differs within its family only in terms of weight, width or slope attributes, then bit 8 should be set. This applies even if the face is part of a large family that includes other faces distinguished by other attributes. Setting bit 8 serves as an indicator to apps that assume the WWS model that name IDs 1 and 2 or IDs 16 and 17 are consistent with the WWS model and no further treatment is required, including checking to see whether name IDs 21 and 22 are present. Hence, when bit 8 is set, name IDs 21 and 22 are never required and should not be included. If a face differs within its family from Regular by attributes other than weight, width or slope, then bit 8 should *not* be set, and name IDs 21 and 22 should be included. By having bit 8 not set, that serves as an indicator to apps that assume a WWS model that they should look for name IDs 21 and 22, or that some other treatment of names could be required. The STAT table was introduced in a later version of OpenType, after bit 8 and name IDs 21 and 22 were defined. The STAT table was introduced, in part, to solve the same kind of requirement but in a more general way that could be useful for applications assuming other family models. If a face has attributes other than weight, width or slope and does not have name IDs 21 and 22, some applications that assume a WWS model could be able to support that font using information in the STAT table. However, even if a STAT table is present (as is required for variable fonts), the recommendations above regarding bit 8 and name IDs 21 and 22 should still be followed. In this context, “typographic family” is the Microsoft Unicode string for name ID 16, if present, else the Microsoft Unicode string for name ID 1; “weight” is OS/2.usWeightClass; “width” is OS/2.usWidthClass; “slope” is OS/2.fsSelection bit 0 (ITALIC) and bit 9 (OBLIQUE). Bit 9: If bit 9 is set, then this font is to be considered an “oblique” style by processes which make a distinction between oblique and italic styles, such as Cascading Style Sheets font matching. For example, a font created by algorithmically slanting an upright face will set this bit. If a font has a version 4 or later OS/2 table and this bit is not set, then this font is not to be considered an “oblique” style. For example, a font that has a classic italic design will not set this bit. This bit, unlike the ITALIC bit (bit 0), is not related to style-linking in applications that assume a four-member font-family model comprised of regular, italic, bold and bold italic. It may be set or unset independently of the ITALIC bit. In most cases, if OBLIQUE is set, then ITALIC will also be set, though this is not required. Bit 15: Bit 15 is permanently reserved. It has been used in some legacy implementations and could result in special behavior in some implementations. Use of this bit is deprecated. |
||||||||||||||||||||||||||||||||||||||||||||||||
| Version differences: |
Versions 0 to 3: Only bit 0 (italic) to bit 6 (regular) are assigned. Bits 7 to 15 are reserved and must be set to 0. Applications should ignore bits 7 to 15 in a font that has a version 0 to version 3 OS/2 table.
Version 4 to 5: Bits 7 to 9 were defined in version 4 (OpenType 1.5). Bits 10 to 15 are reserved and must be set to 0. Applications should ignore bits 10 to 15 in a font that has a version 4 or version 5 OS/2 table. |
usFirstCharIndex
| Format: | uint16 |
| Description: | 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. |
usLastCharIndex
| Format: | uint16 |
| Description: | 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. |
sTypoAscender
| Format: | FWORD |
| Units: | Font design units |
| Description: | The typographic ascender for this font. This field should be combined with the sTypoDescender and sTypoLineGap values to determine default line spacing.
This field is similar to the ascender field in the 'hhea' table as well as to the usWinAscent field in this table. However, legacy platform implementations used those fields with platform-specific behaviors. As a result, those fields are constrained by backward-compatibility requirements, and they do not ensure consistent layout across implementations. The sTypoAscender, sTypoDescender and sTypoLineGap fields are intended to allow applications to lay out documents in a typographically correct and portable fashion.
|
sTypoDescender
| Format: | FWORD |
| Units: | Font design units |
| Description: | The typographic descender for this font. This field should be combined with the sTypoAscender and sTypoLineGap values to determine default line spacing.
This field is similar to the descender field in the 'hhea' table as well as to the usWinDescent field in this table. However, legacy platform implementations used those fields with platform-specific behaviors. As a result, those fields are constrained by backward-compatibility requirements, and they do not ensure consistent layout across implementations. The sTypoAscender, sTypoDescender and sTypoLineGap fields are intended to allow applications to lay out documents in a typographically correct and portable fashion. The USE_TYPO_METRICS flag (bit 7) of the fsSelection field is used to choose between using sTypo* values or usWin* values for default line metrics. See fsSelection for additional details. It is not a general requirement that sTypoAscender - sTypoDescender be equal to unitsPerEm. These values should be set to provide default line spacing appropriate for the primary languages the font is designed to support. For CJK (Chinese, Japanese, and Korean) fonts that are intended to be used for vertical (as well as horizontal) layout, the required value for sTypoDescender is that which describes the bottom 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 1000 × 1000 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. Also see the Recommendations Section for more on this field. |
sTypoLineGap
| Format: | FWORD |
| Units: | Font design units |
| Description: |
The typographic line gap for this font. This field should be combined with the sTypoAscender and sTypoDescender values to determine default line spacing.
This field is similar to the lineGap field in the 'hhea' table. However, legacy platform implementations treat that field with platform-specific behaviors. As a result, that field is constrained by backward-compatibility requirements, and does not ensure consistent layout across implementations. The sTypoAscender, sTypoDescender and sTypoLineGap fields are intended to allow applications to lay out documents in a typographically correct and portable fashion. The USE_TYPO_METRICS flag (bit 7) of the fsSelection field is used to choose between using sTypo* values or usWin* values for default line metrics. See fsSelection for additional details. |
usWinAscent
| Format: | UFWORD |
| Units: | Font design units |
| Description: |
The “Windows ascender” metric. This should be used to specify the height above the baseline for a clipping region.
This is similar to the sTypoAscender field, and also to the ascender field in the 'hhea' table. There are important differences between these, however. In the Windows GDI implementation, the usWinAscent and usWinDescent values have been used to determine the size of the bitmap surface in the TrueType rasterizer. Windows GDI will clip any portion of a TrueType glyph outline that appears above the usWinAscent value. If any clipping is unacceptable, then the value should be set greater than or equal to yMax. Note: This pertains to the default position of glyphs, not their final position in layout after data from the GPOS or 'kern' table has been applied. Also, this clipping behavior interacts with the VDMX table: if a VDMX table is present and there is data for the current device aspect ratio and rasterization size, then the VDMX data will supersede the usWinAscent and usWinDescent values. Some legacy applications use the usWinAscent and usWinDescent values to determine default line spacing. This is strongly discouraged. The sTypo* fields should be used for this purpose. Note that some applications use either the usWin* values or the sTypo* values to determine default line spacing, depending on whether the USE_TYPO_METRICS flag (bit 7) of the fsSelection field is set. This could be useful to provide compatibility with legacy documents using older fonts, while also providing better and more-portable layout using newer fonts. See fsSelection for additional details. Applications that use the sTypo* fields for default line spacing can use the usWin* values to determine the size of a clipping region. Some applications use a clipping region for editing scenarios to determine what portion of the display surface to re-draw when text is edited, or how large a selection rectangle to draw when text is selected. This is an appropriate use for the usWin* values. Early versions of this specification suggested that the usWinAscent value be computed as the yMax for all characters in the Windows “ANSI” character set. For new fonts, the value should be determined based on the primary languages the font is designed to support, and should take into consideration additional height that could be required to accommodate tall glyphs or mark positioning. |
usWinDescent
| Format: | UFWORD |
| Units: | Font design units |
| Description: |
The “Windows descender” metric. This should be used to specify the vertical extent below the baseline for a clipping region.
This is similar to the sTypoDescender field, and also to the descender field in the 'hhea' table. There are important differences between these, however. Some of these differences are described below. In addition, the usWinDescent value treats distances below the baseline as positive values; thus, usWinDescent is usually a positive value, while sTypoDescender and hhea.descender are usually negative. In the Windows GDI implementation, the usWinDescent and usWinAscent values have been used to determine the size of the bitmap surface in the TrueType rasterizer. Windows GDI will clip any portion of a TrueType glyph outline that appears below (-1 × usWinDescent). If any clipping is unacceptable, then the value should be set greater than or equal to (-yMin). Note: This pertains to the default position of glyphs, not their final position in layout after data from the GPOS or 'kern' table has been applied. Also, this clipping behavior interacts with the VDMX table: if a VDMX table is present and there is data for the current device aspect ratio and rasterization size, then the VDMX data will supersede the usWinAscent and usWinDescent values. Some legacy applications use the usWinAscent and usWinDescent values to determine default line spacing. This is strongly discouraged. The sTypo* fields should be used for this purpose. Note that some applications use either the usWin* values or the sTypo* values to determine default line spacing, depending on whether the USE_TYPO_METRICS flag (bit 7) of the fsSelection field is set. This could be useful to provide compatibility with legacy documents using older fonts, while also providing better and more-portable layout using newer fonts. See fsSelection for additional details. Applications that use the sTypo* fields for default line spacing can use the usWin* values to determine the size of a clipping region. Some applications use a clipping region for editing scenarios to determine what portion of the display surface to re-draw when text is edited, or how large a selection rectangle to draw when text is selected. This is an appropriate use for the usWin* values. Early versions of this specification suggested that the usWinDescent value be computed as -yMin for all characters in the Windows “ANSI” character set. For new fonts, the value should be determined based on the primary languages the font is designed to support, and should take into consideration additional vertical extent that could be required to accommodate glyphs with low descenders or mark positioning. |
ulCodePageRange*
ulCodePageRange1 (bits 0 – 31)
ulCodePageRange2 (bits 32 – 63)
| Format: | uint32[2] (64 bits total) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Title: | Code Page Character Range | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | This field is used to specify the code pages encompassed by the font file in the 'cmap' subtable for platform 3, encoding ID 1 (Windows platform, Unicode BMP). If the font file is encoding ID 0, then the Symbol Character Set bit should be set.
If a given 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. All reserved fields must be zero. Each uint32 is in Big-Endian form.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Version differences: |
Version 0: These fields were not defined in version 0. If the size of a version 0 OS/2 table extends beyond the usWinDescent field, additional data beyond the usWinDescent field should be ignored.
Version 1: Bit 8 was not assigned in version 1. All other currently assigned bits were defined in version 1. Version 2 and later: All currently assigned bits were defined in version 2. |
sxHeight
| Format: | FWORD |
| Units: | Font design units |
| Description: | This metric specifies the distance between the baseline and the approximate height of non-ascending lowercase letters measured in font design units. 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. |
| Version differences: |
Version 0, version 1: This field was not defined in version 0 or version 1. If the size of a version 0 OS/2 table extends beyond the usWinDescent field, or if the size of a version 1 OS/2 table extends beyond the code page range fields, this additional data should be ignored.
Version 2 and later: This field was defined in version 2 of the OS/2 table. |
sCapHeight
| Format: | FWORD |
| Units: | Font design units |
| Description: | This metric specifies the distance between the baseline and the approximate height of uppercase letters measured in font design units. 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. |
| Version differences: |
Version 0, version 1: This field was not defined in version 0 or version 1. If the size of a version 0 OS/2 table extends beyond the usWinDescent field, or if the size of a version 1 OS/2 table extends beyond the code page range fields, this additional data should be ignored.
Version 2 and later: This field was defined in version 2 of the OS/2 table. |
usDefaultChar
| Format: | uint16 |
| Description: | This is the Unicode code point, in UTF-16 encoding, of a character that can be used for a default glyph if a requested character is not supported in the font. If the value of this field is zero, glyph ID 0 is to be used for the default character. This field cannot represent supplementary-plane character values (code points greater than 0xFFFF), and so applications are strongly discouraged from using this field. |
| Version differences: |
Version 0, version 1: This field was not defined in version 0 or version 1. If the size of a version 0 OS/2 table extends beyond the usWinDescent field, or if the size of a version 1 OS/2 table extends beyond the code page range fields, this additional data should be ignored.
Version 2 and later: This field was defined in version 2 of the OS/2 table. |
usBreakChar
| Format: | uint16 |
| Description: | This is the Unicode code point, in UTF-16 encoding, of a character that can be used as a default break character. The break character is used to separate words and justify text. Most fonts specify U+0020 SPACE as the break character. This field cannot represent supplementary-plane character values (code points greater than 0xFFFF), and so applications are strongly discouraged from using this field. |
| Version differences: |
Version 0, version 1: This field was not defined in version 0 or version 1. If the size of a version 0 OS/2 table extends beyond the usWinDescent field, or if the size of a version 1 OS/2 table extends beyond the code page range fields, this additional data should be ignored.
Version 2 and later: This field was defined in version 2 of the OS/2 table. |
usMaxContext
| Format: | uint16 |
| Description: | 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 affects the line breaking. For chaining contextual lookups, the length of the string (covered glyph) + (input sequence) + (lookahead sequence) should be considered. |
| Version differences: |
Version 0, version 1: This field was not defined in version 0 or version 1. If the size of a version 0 OS/2 table extends beyond the usWinDescent field, or if the size of a version 1 OS/2 table extends beyond the code page range fields, this additional data should be ignored.
Version 2 and later: This field was defined in version 2 of the OS/2 table. |
usLowerOpticalPointSize
| Format: | uint16 |
| Units: | TWIPs |
| Description: | This field is used for fonts with multiple optical styles.
This value is the lower value of the size range for which this font has been designed. The units for this field are TWIPs (one-twentieth of a point, or 1440 per inch). The value is inclusive — meaning that that font was designed to work best at this point size through, but not including, the point size indicated by usUpperOpticalPointSize. When used with other optical-size-variant fonts within a typographic family that also specify usLowerOpticalPointSize and usUpperOpticalPointSize values, it would be expected that another font has the usUpperOpticalPointSize field set to the same value as the value in this field, unless this font is designed for the lowest size range among the fonts in the family. The smallest font in an optical-size set should set this value to 0. When working across multiple optical-size-variant fonts within a typographic family, there should be no intentional gaps or overlaps in the ranges. The usLowerOpticalPointSize value must be less than usUpperOpticalPointSize. The maximum valid value is 0xFFFE. For fonts that were not designed for multiple optical-size variants, this field should be set to 0 (zero), and usUpperOpticalPointSize should be set to 0xFFFF. Note: Use of this field has been superseded by the STAT table. See Recommendations Section for more information. |
| Version differences: |
Versions 0 – 4: This field was not defined in versions 0 – 4. If the size of an OS/2 table extends beyond the last field defined for the given version, this additional data should be ignored.
Version 5: This field was defined in version 5 of the OS/2 table. |
usUpperOpticalPointSize
| Format: | uint16 |
| Units: | TWIPs |
| Description: | This field is used for fonts with multiple optical styles.
This value is the upper value of the size range for which this font has been designed. The units for this field are TWIPs (one-twentieth of a point, or 1440 per inch). The value is exclusive — meaning that that font was designed to work best below this point size down to the usLowerOpticalPointSize threshold. When used with other optical-size-variant fonts within a typographic family that also specify usLowerOpticalPointSize and usUpperOpticalPointSize values, it would be expected that another font has the usLowerOpticalPointSize field set to the same value as the value in this field, unless this font is designed for the highest size range among the fonts in the family. The largest font in an optical-size set should set this value to 0xFFFF, which is interpreted as infinity. When working across multiple optical-size-variant fonts within a typographic family, there should be no intentional gaps or overlaps left in the ranges. The usUpperOpticalPointSize value must be greater than usLowerOpticalPointSize. The minimum valid value for this field is 2 (two). The largest possible inclusive point size represented by this field is 3276.65 points; any higher values would be represented as infinity. For fonts that were not designed for multiple optical-size variants, this field should be set to 0xFFFF, and usLowerOpticalPointSize should be set to 0 (zero). Note: Use of this field has been superseded by the STAT table. See Recommendations Section for more information. |
| Version differences: |
Versions 0 – 4: This field was not defined in versions 0 – 4. If the size of an OS/2 table extends beyond the last field defined for the given version, this additional data should be ignored.
Version 5: This field was defined in version 5 of the OS/2 table. |
OS/2 Table and OpenType Font Variations
In variable fonts, default line metrics should always be set using the sTypoAscender, sTypoDescender and sTypoLineGap values, and the USE_TYPO_METRICS flag in the fsSelection field should be set. The ascender, descender and lineGap fields in the 'hhea' table should be set to the same values as sTypoAscender, sTypoDescender and sTypoLineGap. The usWinAscent and usWinDescent fields should be used to specify a recommended clipping rectangle.
In a variable font, various font-metric values within the OS/2 table might need to be adjusted for different variation instances. Variation data for OS/2 entries can be provided in the metrics variations (MVAR) table. Different OS/2 entries are associated with particular variation data in the MVAR table using value tags, as follows:
| OS/2 entry | Tag |
|---|---|
| sCapHeight | 'cpht' |
| sTypoAscender | 'hasc' |
| sTypoDescender | 'hdsc' |
| sTypoLineGap | 'hlgp' |
| sxHeight | 'xhgt' |
| usWinAscent | 'hcla' |
| usWinDescent | 'hcld' |
| yStrikeoutPosition | 'stro' |
| yStrikeoutSize | 'strs' |
| ySubscriptXOffset | 'sbxo' |
| ySubScriptXSize | 'sbxs' |
| ySubscriptYOffset | 'sbyo' |
| ySubscriptYSize | 'sbys' |
| ySuperscriptXOffset | 'spxo' |
| ySuperscriptXSize | 'spxs' |
| ySuperscriptYOffset | 'spyo' |
| ySuperscriptYSize | 'spys' |
Note: The usWeightClass and usWidthClass values are not adjusted by variation data since these correspond to 'wght' and 'wdth' variation axes that can be used to define a font’s variation space. Appropriate usWeightClass and usWidthClass values for a variation instance can be derived from 'wght' and 'wdth' user coordinates that are used to select a particular variation instance. For 'wdth' values greater than 200, the usWidthClass value is clamped to 9. See the discussion of the 'wght' and 'wdth' axes in the OpenType Design-Variation Axis Tag Registry for details on the relationship between these OS/2 fields and the corresponding design axes.
Note: The usLowerOpticalPointSize and usUpperOpticalPointSize values are not adjusted by variation data. These values (now superseded by the STAT table) are used to indicate a range of sizes for which a given font has been designed. It is assumed that variation that targets different sizes will be implemented using the 'opsz' variation axis. If a variable font supports 'opsz' as an axis of variation, then the usLowerOpticalPointSize and usUpperOpticalPointSize fields can be set to the same values as the minValue and maxValue fields for the 'opsz' axis in the 'fvar' table.
To have variable line metrics in a variable font, the 'hasc', 'hdsc' and 'hlgp' value tags should be used in the MVAR table to vary the ascender, descender and line gap values from defaults specified in the sTypoAscender, sTypoDescender and sTypoLineGap fields. The 'hcla' and 'hcld' value tags can be used in addition to vary the size of a clipping region from the default specified in the winAscent and winDescent fields. Other metrics can be varied using value tags listed above.
For general information on OpenType Font Variations, see the chapter, OpenType Font Variations Overview.
Collaborate with us on GitHub
The source for this content can be found on GitHub, where you can also create and review issues and pull requests. For more information, see our contributor guide.
OpenType specification