Verify that family names in the name table are consistent across all fonts in the family. Checks Typographic Family name (nameID 16) if present, otherwise uses Font Family name (nameID 1)
- Per the OpenType spec:
“…many existing applications that use this pair of names assume that a Font Family name is shared by at most four fonts that form a font style-linking group”
“For extended typographic families that includes fonts other than the four basic styles(regular, italic, bold, bold italic), it is strongly recommended that name IDs 16 and 17 be used in fonts to create an extended, typographic grouping.”
“If name ID 16 is absent, then name ID 1 is considered to be the typographic family name.”
Fonts within a font family all must have consistent names in the Typographic Family name (nameID 16) or Font Family name (nameID 1), depending on which it uses.
Inconsistent font/typographic family names across fonts in a family can result in unexpected behaviors, such as broken style linking.
Originally proposed at https://github.com/fonttools/fontbakery/issues/4112
Verify that each group of fonts with the same nameID 1 has maximum of 4 fonts.
Per the OpenType spec:
‘The Font Family name […] should be shared among at most four fonts that differ only in weight or style […]’
Originally proposed at https://github.com/fonttools/fontbakery/pull/2372
Check name table for empty records.
Check the name table for empty records, as this can cause problems in Adobe apps.
Originally proposed at https://github.com/fonttools/fontbakery/pull/2369
Name table ID 6 (PostScript name) must be consistent across platforms.
The PostScript name entries in the font’s ‘name’ table should be consistent across platforms.
This is the TTF/CFF2 equivalent of the CFF ‘name/postscript_vs_cff’ check.
Originally proposed at https://github.com/fonttools/fontbakery/pull/2394
CFF table FontName must match name table ID 6 (PostScript name).
The PostScript name entries in the font’s ‘name’ table should match the FontName string in the ‘CFF ‘ table.
The ‘CFF ‘ table has a lot of information that is duplicated in other tables. This information should be consistent across tables, because there’s no guarantee which table an app will get the data from.
Originally proposed at https://github.com/fonttools/fontbakery/pull/2229
PostScript name follows OpenType specification requirements?
Originally proposed at https://github.com/miguelsousa/openbakery/issues/62
Font follows the family naming recommendations?
Legacy check originally simply called ‘check/071’. We used to lack richer metadata back in 2015. We’re open to further improvements to this description.
Checking correctness of monospaced metadata.
There are various metadata in the OpenType spec to specify if a font is monospaced or not. If the font is not truly monospaced, then no monospaced metadata should be set (as sometimes they mistakenly are…)
Requirements for monospace fonts:
post.isFixedPitch - “Set to 0 if the font is proportionally spaced, non-zero if the font is not proportionally spaced (monospaced)” (https://www.microsoft.com/typography/otspec/post.htm)
hhea.advanceWidthMax must be correct, meaning no glyph’s width value is greater. (https://www.microsoft.com/typography/otspec/hhea.htm)
OS/2.panose.bProportion must be set to 9 (monospace) on latin text fonts.
OS/2.panose.bSpacing must be set to 3 (monospace) on latin hand written or latin symbol fonts.
Spec says: “The PANOSE definition contains ten digits each of which currently describes up to sixteen variations. Windows uses bFamilyType, bSerifStyle and bProportion in the font mapper to determine family type. It also uses bProportion to determine if the font is monospaced.” (https://www.microsoft.com/typography/otspec/os2.htm#pan
OS/2.xAvgCharWidth must be set accurately. “OS/2.xAvgCharWidth is used when rendering monospaced fonts, at least by Windows GDI” (http://typedrawers.com/discussion/comment/15397/#Comment_15397)
Also we should report an error for glyphs not of average width.
Please also note:
Thomas Phinney told us that a few years ago (as of December 2019), if you gave a font a monospace flag in Panose, Microsoft Word would ignore the actual advance widths and treat it as monospaced.
Legacy check originally simply called ‘check/033’. We used to lack richer metadata back in 2015. We’re open to further improvements to this description.
Check name table IDs 1, 2, 16, 17 to conform to Italic style.
This check ensures that several entries in the name table conform to the font’s Upright or Italic style, namely IDs 1 & 2 as well as 16 & 17 if they’re present.
Originally proposed at https://github.com/fonttools/fontbakery/issues/3666
Does full font name begin with the font family name?
The FULL_FONT_NAME entry in the ‘name’ table should start with the same string as the Family Name (FONT_FAMILY_NAME, TYPOGRAPHIC_FAMILY_NAME or WWS_FAMILY_NAME).
If the Family Name is not included as the first part of the Full Font Name, and the user embeds the font in a document using a Microsoft Office app, the app will fail to render the font when it opens the document again.
NOTE: Up until version 1.5, the OpenType spec included the following exception in the definition of Full Font Name:
“An exception to the [above] definition of Full font name is for Microsoft platform strings for CFF OpenType fonts: in this case, the Full font name string must be identical to the PostScript FontName in the CFF Name INDEX.”
Legacy check originally simply called ‘check/068’. We used to lack richer metadata back in 2015. We’re open to further improvements to this description.
Description strings in the name table must not contain copyright info.
Legacy check originally simply called ‘check/031’. We used to lack richer metadata back in 2015. We’re open to further improvements to this description.