Skip to content

OS/2 Table, Subscript and Superscript Parameter Specification #1232

@alex-phil

Description

@alex-phil

Description

I would like to suggest improvements to the specification of the following entries in the OS/2 table:

  • ySubscriptXSize
  • ySubscriptYSize
  • ySubscriptXOffset
  • ySubscriptYOffset
  • ySuperscriptXSize
  • ySuperscriptYSize
  • ySuperscriptXOffset
  • ySuperscriptYOffset

The current specification does not seem to be clear enough whether the respective values are meant to be scaling factors or absolute values. Let me discuss the current Comments to ySuperscriptYSize:

  1. “If a font has two recommended sizes for superscripts, e.g., numerics and other, the numeric sizes should be stressed.”
  2. “This size field maps to the em size of the font being used for a superscript.”
  3. “The vertical font size specifies a font designer’s recommended vertical size for superscript glyphs associated with this font.”
  4. “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.”
  5. “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.”

(1) seems reasonably clear. The specification acknowledges that in some font designs, superscript numerals might be designed at a different size than superscript letters. If that is the case, the calculation of the ySuperScriptYSize value should be based on the numeric superscripts, not the alphabetic ones. However, the expression “the numeric sizes” should be changed to “the size of the numeric superscripts” for clarity.

(2) is where the confusion starts. What does ”maps to” mean in this context? “Mapping” usually means a functional relationship f(x) = y, and in this sense, the terms “map” and “mapping” seem to be used in the specification of usWidthClass, for instance. But it remains entirely unclear what “maps to” means in sentence (2).

Now, from (3) and (4), the reader will most likely understand that the ySuperscriptYSize field specifies the height of superscript glyphs as absolute values in font units: “the vertical font size (field) specifies a font designer’s recommended vertical size for superscript glyphs associated with this font”, “this field specifies the recommended nominal height for those superscript glyphs”. When someone talks about specifying the “nominal height” of an object, it is natural to understand that they mean the intended absolute height of the object, regardless of the eventual realization. So (3) and (4), naturally, tell the font designer this: just put in the absolute height of your superscript glyphs in font units.

From (5), however, the reader will gain a very different understanding. Suppose the value entered in ySuperscriptYSize is meant to be absolute, then in the given example, 205 is the intended height of the superscript glyphs. But later it is said this would be “1/10th the size of the normal glyph.” But this is clearly absurd: no normal glyph in a 2048 UPM font is 2048 units tall. So “1/10th the size of the normal glyph” can only hold if 205/2048 is being computed as a scaling factor, not if 205 is compared against any actual glyph height.

In short, the wording of the sentences (3) and (4) is inconsistent with the example given in (5). The specification is genuinely contradictory at this point, and should be amended.

Does that make sense, or is there a misunderstanding on my part?

Page URL

https://learn.microsoft.com/de-de/typography/opentype/spec/

Content source URL

https://github.com/MicrosoftDocs/typography/blob/live/typographydocs/opentype/spec/index.md

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions