If you think a check is flawed or have an idea for a check, please file an issue at https://github.com/fonttools/fontbakery/issues and remember to include a pointer to the repo and branch you're checking.

Summary

Meaning of check results:

• 💥 An ERROR is something wrong with FontBakery itself, possibly a bug.
• 🔥 A FAIL is a problem with the font that must be fixed.
• ⚠️ A WARN is something that you should consider addressing.
• ℹ️ An INFO result simply prints something useful. Typically stats.
• ✅ A PASS means the font looks good for the given checking routine.
• ⏩ And a SKIP happens when the check does not apply to the given font.

If you get ERRORs, please help us improve the tool by reporting them at our issue tracker.

(but other kinds of bug reports and/or feature requests are also always welcome, of course!)

FontBakery version: 0.9.2

Section: Google Fonts

Ensure that all variable font files have the same set of axes and axis ranges.

In order to facilitate the construction of intuitive and friendly user interfaces, all variable font files in a given family should have the same set of variation axes. Also, each axis must have a consistent setting of min/max value ranges accross all the files.

All tabular figures must have the same width across the RIBBI-family.

Tabular figures need to have the same metrics in all styles in order to allow tables to be set with proper typographic control, but to maintain the placement of decimals and numeric columns between rows.

Here's a good explanation of this: https://www.typography.com/techniques/fonts-for-financials/#tabular-figs

Does font file include unacceptable control character glyphs?

Use of some unacceptable control characters in the U+0000 - U+001F range can lead to rendering issues on some platforms.

Acceptable control characters are defined as .null (U+0000) and CR (U+000D) for this test.

Ensure Italic styles have Roman counterparts.

For each font family on Google Fonts, every Italic style must have a Roman sibling.

This kind of problem was first observed at [1] where the Bold style was missing but BoldItalic was included.

[1] https://github.com/google/fonts/pull/1482

Check axis ordering on the STAT table.

This is (for now) a merely informative check to detect what's the axis ordering declared on the STAT table of fonts in the Google Fonts collection.

We may later update this to enforce some unified axis ordering scheme, yet to be determined.

Check README.md has a sample image.

In order to showcase what a font family looks like, the project's README.md file should ideally include a sample image and highlight it in the upper portion of the document, no more than 10 lines away from the top of the file.

Checking file is named canonically.

A font's filename must be composed as "-.ttf":

• Nunito-Regular.ttf

• Oswald-BoldItalic.ttf

Variable fonts must list the axis tags in alphabetical order in square brackets and separated by commas:

• Roboto[wdth,wght].ttf

• Familyname-Italic[wght].ttf

Does DESCRIPTION file contain broken links?

The snippet of HTML in the DESCRIPTION.en_us.html file is added to the font family webpage on the Google Fonts website. For that reason, all hyperlinks in it must be properly working.

URLs on DESCRIPTION file must not display http(s) prefix.

The snippet of HTML in the DESCRIPTION.en_us.html file is added to the font family webpage on the Google Fonts website.

Google Fonts has a content formatting policy for that snippet that expects the text content of links not to include the http:// or https:// prefixes.

Does DESCRIPTION file contain a upstream Git repo URL?

The contents of the DESCRIPTION.en-us.html file are displayed on the Google Fonts website in the about section of each font family specimen page.

Since all of the Google Fonts collection is composed of libre-licensed fonts, this check enforces a policy that there must be a hypertext link in that page directing users to the repository where the font project files are made available.

Such hosting is typically done on sites like Github, Gitlab, GNU Savannah or any other git-based version control service.

Is this a proper HTML snippet?

Sometimes people write malformed HTML markup. This check should ensure the file is good.

Additionally, when packaging families for being pushed to the google/fonts git repo, if there is no DESCRIPTION.en_us.html file, some older versions of the add_font.py tool insert a placeholder description file which contains invalid html. This file needs to either be replaced with an existing description file or edited by hand.

DESCRIPTION.en_us.html must have more than 200 bytes.

DESCRIPTION.en_us.html should end in a linebreak.

Some older text-handling tools sometimes misbehave if the last line of data in a text file is not terminated with a newline character (also known as '\n').

We know that this is a very small detail, but for the sake of keeping all DESCRIPTION.en_us.html files uniformly formatted throughout the GFonts collection, we chose to adopt the practice of placing this final linebreak character on them.

Check METADATA.pb parse correctly.

The purpose of this check is to ensure that the METADATA.pb file is not malformed.

Font designer field in METADATA.pb must not be 'unknown'.

Font designer field in METADATA.pb must not contain 'Multiple designers'.

For a while the string "Multiple designers" was used as a placeholder on METADATA.pb files. We should replace all those instances with actual designer names so that proper credits are displayed on the Google Fonts family specimen pages.

If there's more than a single designer, the designer names must be separated by commas.

Multiple values in font designer field in METADATA.pb must be separated by commas.

We must use commas instead of forward slashes because the server-side code at the fonts.google.com directory will segment the string on the commas into a list of names and display the first item in the list as the "principal designer" while the remaining names are identified as "contributors".

See eg https://fonts.google.com/specimen/Rubik

Does METADATA.pb copyright field contain broken links?

Ensure METADATA.pb lists all font binaries.

The set of font binaries available, except the ones on a "static" subdir, must match exactly those declared on the METADATA.pb file.

Also, to avoid confusion, we expect that font files (other than statics) are not placed on subdirectories.

Ensure METADATA.pb category field is valid.

There are only five acceptable values for the category field in a METADATA.pb file:

• MONOSPACE

• SANS_SERIF

• SERIF

• DISPLAY

• HANDWRITING

This check is meant to avoid typos in this field.

Checking OS/2 fsType does not impose restrictions.

The fsType in the OS/2 table is a legacy DRM-related field. Fonts in the Google Fonts collection must have it set to zero (also known as "Installable Embedding"). This setting indicates that the fonts can be embedded in documents and permanently installed by applications on remote systems.

More detailed info is available at: https://docs.microsoft.com/en-us/typography/opentype/spec/os2#fstype

Checking OS/2 achVendID.

Microsoft keeps a list of font vendors and their respective contact info. This list is updated regularly and is indexed by a 4-char "Vendor ID" which is stored in the achVendID field of the OS/2 table.

Registering your ID is not mandatory, but it is a good practice since some applications may display the type designer / type foundry contact info on some dialog and also because that info will be visible on Microsoft's website:

https://docs.microsoft.com/en-us/typography/vendors/

This check verifies whether or not a given font's vendor ID is registered in that list or if it has some of the default values used by the most common font editors.

Each new FontBakery release includes a cached copy of that list of vendor IDs. If you registered recently, you're safe to ignore warnings emitted by this check, since your ID will soon be included in one of our upcoming releases.

Check Google Fonts glyph coverage.

Google Fonts expects that fonts in its collection support at least the minimal set of characters defined in the GF-latin-core glyph-set.

Check for METADATA subsets with zero support.

This check ensures that the subsets specified on a METADATA.pb file are actually supported (even if only partially) by the font files.

Subsets for which none of the codepoints are supported will cause the check to FAIL.

Check for codepoints not covered by METADATA subsets.

This check ensures that all encoded glyphs in the font are covered by a subset declared in the METADATA.pb. Google Fonts splits the font into a set of subset fonts based on the contents of the subsets field and the subset definitions in the glyphsets repository.

Any encoded glyphs which are not by any of these subset definitions will not be served in the subsetted fonts, and so will be unreachable to the end user.

Substitute copyright, registered and trademark symbols in name table entries.

Check the OS/2 usWeightClass is appropriate for the font's best SubFamily name.

Google Fonts expects variable fonts, static ttfs and static otfs to have differing OS/2 usWeightClass values.

• For Variable Fonts, Thin-Black must be 100-900

• For static ttfs, Thin-Black can be 100-900 or 250-900

• For static otfs, Thin-Black must be 250-900

If static otfs are set lower than 250, text may appear blurry in legacy Windows applications.

Glyphsapp users can change the usWeightClass value of an instance by adding a 'weightClass' customParameter.

Check font has a license.

Check license file has good copyright string.

An OFL.txt file's first line should be the font copyright e.g: "Copyright 2019 The Montserrat Project Authors (https://github.com/julietaula/montserrat)"

Check OFL body text is correct.

Check OFL body text is correct. Often users will accidently delete parts of the body text.

Check copyright namerecords match license file.

A known licensing description must be provided in the NameID 14 (LICENSE DESCRIPTION) entries of the name table.

The source of truth for this check (to determine which license is in use) is a file placed side-by-side to your font project including the licensing terms.

Depending on the chosen license, one of the following string snippets is expected to be found on the NameID 13 (LICENSE DESCRIPTION) entries of the name table:

• "This Font Software is licensed under the SIL Open Font License, Version 1.1. This license is available with a FAQ at: https://scripts.sil.org/OFL"

• "Licensed under the Apache License, Version 2.0"

• "Licensed under the Ubuntu Font Licence 1.0."

Currently accepted licenses are Apache or Open Font License. For a small set of legacy families the Ubuntu Font License may be acceptable as well.

When in doubt, please choose OFL for new font projects.

License URL matches License text on name table?

A known license URL must be provided in the NameID 14 (LICENSE INFO URL) entry of the name table.

The source of truth for this check is the licensing text found on the NameID 13 entry (LICENSE DESCRIPTION).

The string snippets used for detecting licensing terms are:

• "This Font Software is licensed under the SIL Open Font License, Version 1.1. This license is available with a FAQ at: https://scripts.sil.org/OFL"

• "Licensed under the Apache License, Version 2.0"

• "Licensed under the Ubuntu Font Licence 1.0."

Currently accepted licenses are Apache or Open Font License. For a small set of legacy families the Ubuntu Font License may be acceptable as well.

When in doubt, please choose OFL for new font projects.

Description strings in the name table must not exceed 200 characters.

An old FontLab version had a bug which caused it to store copyright notices in nameID 10 entries.

In order to detect those and distinguish them from actual legitimate usage of this name table entry, we expect that such strings do not exceed a reasonable length of 200 chars.

Longer strings are likely instances of the FontLab bug.

Show hinting filesize impact.

This check is merely informative, displaying and useful comparison of filesizes of hinted versus unhinted font files.

Ensure files are not too large.

Serving extremely large font files on Google Fonts causes usability issues. This check ensures that file sizes are reasonable.

Version format is correct in 'name' table?

Font has ttfautohint params?

Font has old ttfautohint applied?

Check if font has been hinted with an outdated version of ttfautohint.

EPAR table present in font?

The EPAR table is/was a way of expressing common licensing permissions and restrictions in metadata; while almost nothing supported it, Dave Crossland wonders that adding it to everything in Google Fonts could help make it more popular.

More info is available at: https://davelab6.github.io/epar/

Is the Grid-fitting and Scan-conversion Procedure ('gasp') table set to optimize rendering?

Traditionally version 0 'gasp' tables were set so that font sizes below 8 ppem had no grid fitting but did have antialiasing. From 9-16 ppem, just grid fitting. And fonts above 17ppem had both antialiasing and grid fitting toggled on. The use of accelerated graphics cards and higher resolution screens make this approach obsolete. Microsoft's DirectWrite pushed this even further with much improved rendering built into the OS and apps.

In this scenario it makes sense to simply toggle all 4 flags ON for all font sizes.

Make sure family name does not begin with a digit.

Font family names which start with a numeral are often not discoverable in Windows applications.

Are there non-ASCII characters in ASCII-only NAME table entries?

The OpenType spec requires ASCII for the POSTSCRIPT_NAME (nameID 6).

For COPYRIGHT_NOTICE (nameID 0) ASCII is required because that string should be the same in CFF fonts which also have this requirement in the OpenType spec.

Note: A common place where we find non-ASCII strings is on name table entries with NameID > 18, which are expressly for localising the ASCII-only IDs into Hindi / Arabic / etc.

METADATA.pb: check if fonts field only has unique "full_name" values.

METADATA.pb: check if fonts field only contains unique style:weight pairs.

METADATA.pb license is "APACHE2", "UFL" or "OFL"?

METADATA.pb should contain at least "menu" and "latin" subsets.

METADATA.pb subsets should be alphabetically ordered.

Check METADATA.pb includes production subsets.

Check METADATA.pb file includes the same subsets as the family in production.

METADATA.pb: Copyright notice is the same in all fonts?

Check that METADATA.pb family values are all the same.

METADATA.pb: According to Google Fonts standards, families should have a Regular style.

METADATA.pb: Regular should be 400.

Checks METADATA.pb font.name field matches family name declared on the name table.

Checks METADATA.pb font.post_script_name matches postscript name declared on the name table.

METADATA.pb font.full_name value matches fullname declared on the name table?

METADATA.pb font.name value should be same as the family name declared on the name table.

This check ensures consistency between the font name declared on the name table and the contents of the METADATA.pb file.

METADATA.pb font.full_name and font.post_script_name fields have equivalent values ?

METADATA.pb font.filename and font.post_script_name fields have equivalent values?

METADATA.pb font.name field contains font name in right format?

METADATA.pb font.full_name field contains font name in right format?

METADATA.pb font.filename field contains font name in right format?

METADATA.pb font.post_script_name field contains font name in right format?

Check name ID 25 to end with "Italic" for Italic VFs.

Due to a bug in (at least) Adobe Indesign, name ID 25 needs to be different for Italic VFs than their Upright counterparts. Google Fonts chooses to append "Italic" here.

Copyright notices match canonical pattern in METADATA.pb

The expected pattern for the copyright string adheres to the following rules:

• It must say "Copyright" followed by a 4 digit year (optionally followed by a hyphen and another 4 digit year)

• Then it must say "The Project Authors"

• And within parentheses, a URL for a git repository must be provided

• The check is case insensitive and does not validate whether the familyname is correct, even though we'd expect it is (and we may soon update the check to validate that aspect as well!)

Here is an example of a valid copyright string:

"Copyright 2017 The Archivo Black Project Authors (https://github.com/Omnibus-Type/ArchivoBlack)"

Copyright notices match canonical pattern in fonts

Copyright notice on METADATA.pb should not contain 'Reserved Font Name'.

METADATA.pb: Copyright notice shouldn't exceed 500 chars.

METADATA.pb: Font filenames match font.filename entries?

Note: This check only looks for files in the current directory.

Font files in subdirectories are checked by these other two checks: - com.google.fonts/check/metadata/undeclared_fonts - com.google.fonts/check/repo/vf_has_static_fonts

We may want to merge them all into a single check.

METADATA.pb font.style "italic" matches font internals?

METADATA.pb font.style "normal" matches font internals?

METADATA.pb font.name and font.full_name fields match the values declared on the name table?

METADATA.pb: Check font name is the same as family name.

METADATA.pb: Check that font weight has a canonical value.

Check METADATA.pb font weights are correct.

Check METADATA.pb font weights are correct.

For static fonts, the metadata weight should be the same as the static font's OS/2 usWeightClass.

For variable fonts, the weight value should be 400 if the font's wght axis range includes 400, otherwise it should be the value closest to 400.

METADATA.pb weight matches postScriptName for static fonts.

METADATA.pb: Font styles are named canonically?

METADATA.pb: Check URL on copyright string is the same as in repository_url field.

Sometimes, perhaps due to copy-pasting, projects may declare different URLs between the font.coyright and the family.sources.repository_url fields.

METADATA.pb: Check for primary_script

Try to guess font's primary script and see if that's set in METADATA.pb. This is an educated guess based on the number of glyphs per script in the font and should be taken with caution.

Stricter unitsPerEm criteria for Google Fonts.

Even though the OpenType spec allows unitsPerEm to be any value between 16 and 16384, the Google Fonts project aims at a narrower set of reasonable values.

The spec suggests usage of powers of two in order to get some performance improvements on legacy renderers, so those values are acceptable.

But values of 500 or 1000 are also acceptable, with the added benefit that it makes upm math easier for designers, while the performance hit of not using a power of two is most likely negligible nowadays.

Additionally, values above 2048 would likely result in unreasonable filesize increases.

Glyphs are similiar to Google Fonts version?

Checking direction of slnt axis angles

The 'slnt' axis values are defined as negative values for a clockwise (right) lean, and positive values for counter-clockwise lean. This is counter-intuitive for many designers who are used to think of a positive slant as a lean to the right.

This check ensures that the slant axis direction is consistent with the specs.

https://docs.microsoft.com/en-us/typography/opentype/spec/dvaraxistag_slnt

Copyright field for this font on METADATA.pb matches all copyright notice entries on the name table ?

Font has all mandatory 'name' table entries?

Length of copyright notice must not exceed 500 characters.

This is an arbitrary max length for the copyright notice field of the name table. We simply don't want such notices to be too long. Typically such notices are actually much shorter than this with a length of roughly 70 or 80 characters.

Familyname must be unique according to namecheck.fontdata.com

We need to check names are not already used, and today the best place to check that is http://namecheck.fontdata.com

Check for font-v versioning.

The git sha1 tagging and dev/release features of Source Foundry font-v tool are awesome and we would love to consider upstreaming the approach into fontmake someday. For now we only emit an INFO if a given font does not yet follow the experimental versioning style, but at some point we may start enforcing it.

Check glyphs do not have components which are themselves components.

There have been bugs rendering variable fonts with nested components. Additionally, some static fonts with nested components have been reported to have rendering and printing issues.

For more info, see: * https://github.com/fonttools/fontbakery/issues/2961 * https://github.com/arrowtype/recursive/issues/412

Check a static ttf can be generated from a variable font.

Google Fonts may serve static fonts which have been generated from variable fonts. This test will attempt to generate a static ttf using fontTool's varLib mutator.

The target font will be the mean of each axis e.g:

VF font axes

• min weight, max weight = 400, 800

• min width, max width = 50, 100

Target Instance

• weight = 600

• width = 75

Check that variable fonts have an HVAR table.

Not having a HVAR table can lead to costly text-layout operations on some platforms, which we want to avoid.

So, all variable fonts on the Google Fonts collection should have an HVAR with valid values.

More info on the HVAR table can be found at: https://docs.microsoft.com/en-us/typography/opentype/spec/otvaroverview#variation-data-tables-and-miscellaneous-requirements

Font enables smart dropout control in "prep" table instructions?

This setup is meant to ensure consistent rendering quality for fonts across all devices (with different rendering/hinting capabilities).

Below is the snippet of instructions we expect to see in the fonts: B8 01 FF PUSHW 0x01FF 85 SCANCTRL (unconditinally turn on dropout control mode) B0 04 PUSHB 0x04 8D SCANTYPE (enable smart dropout control)

"Smart dropout control" means activating rules 1, 2 and 5: Rule 1: If a pixel's center falls within the glyph outline, that pixel is turned on. Rule 2: If a contour falls exactly on a pixel's center, that pixel is turned on. Rule 5: If a scan line between two adjacent pixel centers (either vertical or horizontal) is intersected by both an on-Transition contour and an off-Transition contour and neither of the pixels was already turned on by rules 1 and 2, turn on the pixel which is closer to the midpoint between the on-Transition contour and off-Transition contour. This is "Smart" dropout control.

For more detailed info (such as other rules not enabled in this snippet), please refer to the TrueType Instruction Set documentation.

There must not be VTT Talk sources in the font.

The goal here is to reduce filesizes and improve pageloading when dealing with webfonts.

The VTT Talk sources are not necessary at runtime and endup being just dead weight when left embedded in the font binaries. The sources should be kept on the project files but stripped out when building release binaries.

Are there unwanted Apple tables?

Apple's TrueType reference manual [1] describes SFNT tables not in the Microsoft OpenType specification [2] and these can sometimes sneak into final release files, but Google Fonts should only have OpenType tables.

[1] https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6.html [2] https://docs.microsoft.com/en-us/typography/opentype/spec/

Check a font's STAT table contains compulsory Axis Values.

Check a font's STAT table contains compulsory Axis Values which exist in the Google Fonts Axis Registry.

We cannot determine what Axis Values the user will set for axes such as opsz, GRAD since these axes are unique for each font so we'll skip them.

Check variable font instances

Check a font's fvar instance coordinates comply with our guidelines: https://googlefonts.github.io/gf-guide/variable.html#fvar-instances

All name entries referenced by fvar instances exist on the name table?

The purpose of this check is to make sure that all name entries referenced by variable font instances do exist in the name table.

PPEM must be an integer on hinted fonts.

Hinted fonts must have head table flag bit 3 set.

Per https://docs.microsoft.com/en-us/typography/opentype/spec/head, bit 3 of Head::flags decides whether PPEM should be rounded. This bit should always be set for hinted fonts.

Note: Bit 3 = Force ppem to integer values for all internal scaler math; May use fractional ppem sizes if this bit is clear;

Are there caret positions declared for every ligature?

All ligatures in a font must have corresponding caret (text cursor) positions defined in the GDEF table, otherwhise, users may experience issues with caret rendering.

If using GlyphsApp or UFOs, ligature carets can be defined as anchors with names starting with 'caret_'. These can be compiled with fontmake as of version v2.4.0.

Is there kerning info for non-ligated sequences?

Fonts with ligatures should have kerning on the corresponding non-ligated sequences for text where ligatures aren't used (eg https://github.com/impallari/Raleway/issues/14).

Combined length of family and style must not exceed 27 characters.

According to a GlyphsApp tutorial [1], in order to make sure all versions of Windows recognize it as a valid font file, we must make sure that the concatenated length of the familyname (NameID.FONT_FAMILY_NAME) and style (NameID.FONT_SUBFAMILY_NAME) strings in the name table do not exceed 20 characters.

After discussing the problem in more detail at FontBakery issue #2179 [2] we decided that allowing up to 27 chars would still be on the safe side, though.

[1] https://glyphsapp.com/tutorials/multiple-masters-part-3-setting-up-instances [2] https://github.com/fonttools/fontbakery/issues/2179

Name table entries should not contain line-breaks.

There are some entries on the name table that may include more than one line of text. The Google Fonts team, though, prefers to keep the name table entries short and simple without line breaks.

For instance, some designers like to include the full text of a font license in the "copyright notice" entry, but for the GFonts collection this entry should only mention year, author and other basic info in a manner enforced by com.google.fonts/check/font_copyright

Name table strings must not contain the string 'Reserved Font Name'.

Some designers adopt the "Reserved Font Name" clause of the OFL license. This means that the original author reserves the rights to the family name and other people can only distribute modified versions using a different family name.

Google Fonts published updates to the fonts in the collection in order to fix issues and/or implement further improvements to the fonts. It is important to keep the family name so that users of the webfonts can benefit from the updates. Since it would forbid such usage scenario, all families in the GFonts collection are required to not adopt the RFN clause.

This check ensures "Reserved Font Name" is not mentioned in the name table.

Check family name for GF Guide compliance.

Checks the family name for compliance with the Google Fonts Guide. https://googlefonts.github.io/gf-guide/onboarding.html#new-fonts

If you want to have your family name added to the CamelCase exceptions list, please submit a pull request to the camelcased_familyname_exceptions.txt file.

Similarly, abbreviations can be submitted to the abbreviations_familyname_exceptions.txt file.

These are located in the Lib/fontbakery/data/googlefonts/ directory of the FontBakery source code currently hosted at https://github.com/fonttools/fontbakery/

Directory name in GFonts repo structure must match NameID 1 of the regular.

A static fonts directory with at least two fonts must accompany variable fonts

Variable font family directories kept in the google/fonts git repo may include a static/ subdir containing static fonts.

These files are meant to be served for users that still lack support for variable fonts in their web browsers.

A font repository should not include FontBakery report files

A FontBakery report is ephemeral and so should be used for posting issues on a bug-tracker instead of being hosted in the font project repository.

Check upstream.yaml file contains all required fields

If a family has been pushed using the gftools packager, we must check that all the required fields in the upstream.yaml file have been populated.

Check font follows the Google Fonts vertical metric schema

This check generally enforces Google Fonts’ vertical metrics specifications. In particular: * lineGap must be 0 * Sum of hhea ascender + abs(descender) + linegap must be between 120% and 200% of UPM * Warning if sum is over 150% of UPM

The threshold levels 150% (WARN) and 200% (FAIL) are somewhat arbitrarily chosen and may hint at a glaring mistake in the metrics calculations or UPM settings.

Our documentation includes further information: https://github.com/googlefonts/gf-docs/tree/main/VerticalMetrics

Check if the vertical metrics of a family are similar to the same family hosted on Google Fonts.

If the family already exists on Google Fonts, we need to ensure that the checked family's vertical metrics are similar. This check will test the following schema which was outlined in Font Bakery issue #1162 [1]:

• The family should visually have the same vertical metrics as the Regular style hosted on Google Fonts.

• If the family on Google Fonts has differing hhea and typo metrics, the family being checked should use the typo metrics for both the hhea and typo entries.

• If the family on Google Fonts has use typo metrics not enabled and the family being checked has it enabled, the hhea and typo metrics should use the family on Google Fonts winAscent and winDescent values.

• If the upms differ, the values must be scaled so the visual appearance is the same.

[1] https://github.com/fonttools/fontbakery/issues/1162

Check font follows the Google Fonts CJK vertical metric schema

CJK fonts have different vertical metrics when compared to Latin fonts. We follow the schema developed by dr Ken Lunde for Source Han Sans and the Noto CJK fonts.

Our documentation includes further information: https://github.com/googlefonts/gf-docs/tree/main/Spec#cjk-vertical-metrics

Check if the vertical metrics of a CJK family are similar to the same family hosted on Google Fonts.

Check CJK family has the same vertical metrics as the same family hosted on Google Fonts.

Does the font contain less than 150 CJK characters?

Kana has 150 characters and it's the smallest CJK writing system.

If a font contains less CJK glyphs than this writing system, we inform the user that some glyphs may be encoded incorrectly.

Check variable font instances don't have duplicate names

This check's purpose is to detect duplicate named instances names in a given variable font. Repeating instance names may be the result of instances for several VF axes defined in fvar, but since currently only weight+italic tokens are allowed in instance names as per GF specs, they ended up repeating. Instead, only a base set of fonts for the most default representation of the family can be defined through instances in the fvar table, all other instances will have to be left to access through the STAT table.

Ensure VFs do not contain the ital axis.

The 'ital' axis is not supported yet in Google Chrome.

For the time being, we need to ensure that VFs do not contain this axis. Once browser support is better, we can deprecate this check.

For more info regarding browser support, see: https://arrowtype.github.io/vf-slnt-test/

Ensure VFs with duplexed axes do not vary horizontal advance.

Certain axes, such as grade (GRAD) or roundness (ROND), should not change any advanceWidth or kerning data across the font's design space. This is because altering the advance width of glyphs can cause text reflow.

Validate METADATA.pb axes values are within gf_axisregistry bounds.

Each axis range in a METADATA.pb file must be registered, and within the bounds of the axis definition in the Google Fonts Axis Registry, available at https://github.com/google/fonts/tree/main/axisregistry

Validate METADATA.pb axes tags are defined in gf_axisregistry.

Ensure all axes in a METADATA.pb file are registered in the Google Fonts Axis Registry, available at https://github.com/google/fonts/tree/main/axisregistry

Why does Google Fonts have its own Axis Registry?

We support a superset of the OpenType axis registry axis set, and use additional metadata for each axis. Axes present in a font file but not in this registry will not function via our API. No variable font is expected to support all of the axes here.

Any font foundry or distributor library that offers variable fonts has a implicit, latent, de-facto axis registry, which can be extracted by scanning the library for axes' tags, labels, and min/def/max values. While in 2016 Microsoft originally offered to include more axes in the OpenType 1.8 specification (github.com/microsoft/OpenTypeDesignVariationAxisTags), as of August 2020, this effort has stalled. We hope more foundries and distributors will publish documents like this that make their axes explicit, to encourage of adoption of variable fonts throughout the industry, and provide source material for a future update to the OpenType specification's axis registry.

Validate defaults on fvar table match registered fallback names in GFAxisRegistry.

Check that axis defaults have a corresponding fallback name registered at the Google Fonts Axis Registry, available at https://github.com/google/fonts/tree/main/axisregistry

This is necessary for the following reasons:

To get ZIP files downloads on Google Fonts to be accurate — otherwise the chosen default font is not generated. The Newsreader family, for instance, has a default value on the 'opsz' axis of 16pt. If 16pt was not a registered fallback position, then the ZIP file would instead include another position as default (such as 14pt).

For the Variable fonts to display the correct location on the specimen page.

For VF with no weight axis to be displayed at all. For instance, Ballet, which has no weight axis, was not appearing in sandbox because default position on 'opsz' axis was 16pt, and it was not yet a registered fallback positon.

Validate STAT particle names and values match the fallback names in GFAxisRegistry.

Check that particle names and values on STAT table match the fallback names in each axis entry at the Google Fonts Axis Registry, available at https://github.com/google/fonts/tree/main/axisregistry

Validate VF axes match the ones declared on METADATA.pb.

All font variation axes present in the font files must be properly declared on METADATA.pb so that they can be served by the GFonts API.

Ensure METADATA.pb does not use escaped strings.

In some cases we've seen designer names and other fields with escaped strings in METADATA files. Nowadays the strings can be full unicode strings and do not need escaping.

METADATA.pb: Designers are listed correctly on the Google Fonts catalog?

Google Fonts has a catalog of designers.

This check ensures that the online entries of the catalog can be found based on the designer names listed on the METADATA.pb file.

It also validates the URLs and file formats are all correctly set.

Ensure variable fonts include an avar table.

Most variable fonts should include an avar table to correctly define axes progression rates.

For example, a weight axis from 0% to 100% doesn't map directly to 100 to 1000, because a 10% progression from 0% may be too much to define the 200, while 90% may be too little to define the 900.

If the progression rates of axes is linear, this check can be ignored. Fontmake will also skip adding an avar table if the progression rates are linear. However, we still recommend designers visually proof each instance is at the expected weight, width etc.

On a family update, the DESCRIPTION.en_us.html file should ideally also be updated.

We want to ensure that any significant changes to the font family are properly mentioned in the DESCRIPTION file.

In general, it means that the contents of the DESCRIPTION.en_us.html file will typically change if when font files are updated. Please treat this check as a reminder to do so whenever appropriate!

Check small caps glyphs are available.

Ensure small caps glyphs are available if a font declares smcp or c2sc OT features.

Ensure Stylistic Sets have description.

Stylistic sets should provide description text. Programs such as InDesign, TextEdit and Inkscape use that info to display to the users so that they know what a given stylistic set offers.

OS/2.fsSelection bit 7 (USE_TYPO_METRICS) is set in all fonts.

All fonts on the Google Fonts collection should have OS/2.fsSelection bit 7 (USE_TYPO_METRICS) set. This requirement is part of the vertical metrics scheme established as a Google Fonts policy aiming at a common ground supported by all major font rendering environments.

For more details, read: https://github.com/googlefonts/gf-docs/blob/main/VerticalMetrics/README.md

Below is the portion of that document that is most relevant to this check:

Use_Typo_Metrics must be enabled. This will force MS Applications to use the OS/2 Typo values instead of the Win values. By doing this, we can freely set the Win values to avoid clipping and control the line height with the typo values. It has the added benefit of future line height compatibility. When a new script is added, we simply change the Win values to the new yMin and yMax, without needing to worry if the line height have changed.

Ensure fonts have ScriptLangTags declared on the 'meta' table.

The OpenType 'meta' table originated at Apple. Microsoft added it to OT with just two DataMap records:

• dlng: comma-separated ScriptLangTags that indicate which scripts, or languages and scripts, with possible variants, the font is designed for.

• slng: comma-separated ScriptLangTags that indicate which scripts, or languages and scripts, with possible variants, the font supports.

The slng structure is intended to describe which languages and scripts the font overall supports. For example, a Traditional Chinese font that also contains Latin characters, can indicate Hant,Latn, showing that it supports Hant, the Traditional Chinese variant of the Hani script, and it also supports the Latn script.

The dlng structure is far more interesting. A font may contain various glyphs, but only a particular subset of the glyphs may be truly "leading" in the design, while other glyphs may have been included for technical reasons. Such a Traditional Chinese font could only list Hant there, showing that it’s designed for Traditional Chinese, but the font would omit Latn, because the developers don’t think the font is really recommended for purely Latin-script use.

The tags used in the structures can comprise just script, or also language and script. For example, if a font has Bulgarian Cyrillic alternates in the locl feature for the cyrl BGR OT languagesystem, it could also indicate in dlng explicitly that it supports bul-Cyrl. (Note that the scripts and languages in meta use the ISO language and script codes, not the OpenType ones).

This check ensures that the font has the meta table containing the slng and dlng structures.

All families in the Google Fonts collection should contain the 'meta' table. Windows 10 already uses it when deciding on which fonts to fall back to. The Google Fonts API and also other environments could use the data for smarter filtering. Most importantly, those entries should be added to the Noto fonts.

In the font making process, some environments store this data in external files already. But the meta table provides a convenient way to store this inside the font file, so some tools may add the data, and unrelated tools may read this data. This makes the solution much more portable and universal.

Ensure fonts do not contain any pre-production tables.

Tables such as Debg are useful in the pre-production stages of font development, but add unnecessary bloat to a production font and should be removed before release.

Check font family directory name.

We want the directory name of a font family to be predictable and directly derived from the family name, all lowercased and removing spaces.

Check font can render its own name.

A base expectation is that a font family's regular/default (400 roman) style can render its 'menu name' (nameID 1) in itself.

Check samples can be rendered.

In order to prevent tofu from being seen on fonts.google.com, this check verifies that all samples specified by METADATA.pb can be properly rendered by the font.

Check if category on METADATA.pb matches what can be inferred from the family name.

Sometimes the font familyname contains words that hint at which is the most likely correct category to be declared on METADATA.pb

Check font has the expected color font tables.

COLR v0 fonts are widely supported in most browsers so they do not require an SVG color table. However, some environments (e.g. Safari, Adobe apps) do not currently support COLR v1 so we need to add an SVG table to these fonts, except in the case of variable fonts, since SVG does not support OpenType Variations.

To automatically generate compatible SVG/COLR tables, run the maximum_color tool in nanoemoji: https://github.com/googlefonts/nanoemoji

Color layers should have a minimum brightness

Layers of a COLRv0 font should not be too dark or too bright. When layer colors are set explicitly, they can't be changed and they may turn out illegible against dark or bright backgrounds.

While traditional color-less fonts can be colored in design apps or CSS, a black color definition in a COLRv0 font actually means that that layer will be rendered in black regardless of the background color. This leads to text becoming invisible against a dark background, for instance when using a dark theme in a web browser or operating system.

This check ensures that layer colors are at least 10% bright and at most 90% bright, when not already set to the current color (0xFFFF).

Put an empty glyph on GID 1 right after the .notdef glyph for COLRv0 fonts.

A rendering bug in Windows 10 paints whichever glyph is on GID 1 on top of some glyphs, colored or not. This only occurs for COLR version 0 fonts.

Having a glyph with no contours on GID 1 is a practical workaround for that.

See https://github.com/googlefonts/gftools/issues/609

Noto fonts must have an ARTICLE.en_us.html file

Noto fonts are displayed in a different way on the fonts.google.com web site, and so must also contain an article about them.

Section: Universal

Checking all files are in the same directory.

If the set of font files passed in the command line is not all in the same directory, then we warn the user since the tool will interpret the set of files as belonging to a single family (and it is unlikely that the user would store the files from a single family spreaded in several separate directories).

Each font in a family must have the same set of vertical metrics values.

We want all fonts within a family to have the same vertical metrics so their line spacing is consistent across the family.

Name table records must not have trailing spaces.

Checking OS/2 usWinAscent & usWinDescent.

A font's winAscent and winDescent values should be greater than or equal to the head table's yMax, abs(yMin) values. If they are less than these values, clipping can occur on Windows platforms (https://github.com/RedHatBrand/Overpass/issues/33).

If the font includes tall/deep writing systems such as Arabic or Devanagari, the winAscent and winDescent can be greater than the yMax and absolute yMin values to accommodate vowel marks.

When the 'win' Metrics are significantly greater than the UPM, the linespacing can appear too loose. To counteract this, enabling the OS/2 fsSelection bit 7 (Use_Typo_Metrics), will force Windows to use the OS/2 'typo' values instead. This means the font developer can control the linespacing with the 'typo' values, whilst avoiding clipping by setting the 'win' values to values greater than the yMax and absolute yMin.

Checking OS/2 Metrics match hhea Metrics.

OS/2 and hhea vertical metric values should match. This will produce the same linespacing on Mac, GNU+Linux and Windows.

• Mac OS X uses the hhea values. - Windows uses OS/2 or Win, depending on the OS or fsSelection bit value.

When OS/2 and hhea vertical metrics match, the same linespacing results on macOS, GNU+Linux and Windows. Note that fixing this issue in a previously released font may cause reflow in user documents and unhappy users.

Checking with ots-sanitize.

Do we have the latest version of FontBakery installed?

Running old versions of FontBakery can lead to a poor report which may include false WARNs and FAILs due do bugs, as well as outdated quality assurance criteria.

Older versions will also not report problems that are detected by new checks added to the tool in more recent updates.

Font contains '.notdef' as its first glyph?

The OpenType specification v1.8.2 recommends that the first glyph is the '.notdef' glyph without a codepoint assigned and with a drawing:

The .notdef glyph is very important for providing the user feedback that a glyph is not found in the font. This glyph should not be left without an outline as the user will only see what looks like a space if a glyph is missing and not be aware of the active font’s limitation.

https://docs.microsoft.com/en-us/typography/opentype/spec/recom#glyph-0-the-notdef-glyph

Pre-v1.8, it was recommended that fonts should also contain 'space', 'CR' and '.null' glyphs. This might have been relevant for MacOS 9 applications.

Font contains glyphs for whitespace characters?

Font has **proper** whitespace glyph names?

This check enforces adherence to recommended whitespace (codepoints 0020 and 00A0) glyph names according to the Adobe Glyph List.

Whitespace glyphs have ink?

Font contains all required tables?

According to the OpenType spec https://docs.microsoft.com/en-us/typography/opentype/spec/otff#required-tables

Whether TrueType or CFF outlines are used in an OpenType font, the following tables are required for the font to function correctly:

• cmap (Character to glyph mapping)
• head (Font header)
• hhea (Horizontal header)
• hmtx (Horizontal metrics)
• maxp (Maximum profile)
• name (Naming table)
• OS/2 (OS/2 and Windows specific metrics)
• post (PostScript information)

The spec also documents that variable fonts require the following table:

• STAT (Style attributes)

Depending on the typeface and coverage of a font, certain tables are recommended for optimum quality.

For example:

• the performance of a non-linear font is improved if the VDMX, LTSH, and hdmx tables are present.
• Non-monospaced Latin fonts should have a kern table.
• A gasp table is necessary if a designer wants to influence the sizes at which grayscaling is used under Windows. Etc.

Are there unwanted tables?

Some font editors store source data in their own SFNT tables, and these can sometimes sneak into final release files, which should only have OpenType spec tables.

Check correctness of STAT table strings

On the STAT table, the "Italic" keyword must not be used on AxisValues for variation axes other than 'ital'.

Glyph names are all valid?

Microsoft's recommendations for OpenType Fonts states the following:

'NOTE: The PostScript glyph name must be no longer than 31 characters, include only uppercase or lowercase English letters, European digits, the period or the underscore, i.e. from the set [A-Za-z0-9_.] and should start with a letter, except the special glyph name ".notdef" which starts with a period.'

https://docs.microsoft.com/en-us/typography/opentype/spec/recom#post-table

In practice, though, particularly in modern environments, glyph names can be as long as 63 characters.

According to the "Adobe Glyph List Specification" available at:

https://github.com/adobe-type-tools/agl-specification

Font contains unique glyph names?

Duplicate glyph names prevent font installation on Mac OS X.

Checking with fontTools.ttx

List all superfamily filepaths

This is a merely informative check that lists all sibling families detected by fontbakery.

Only the fontfiles in these directories will be considered in superfamily-level checks.

Each font in set of sibling families must have the same set of vertical metrics values.

We may want all fonts within a super-family (all sibling families) to have the same vertical metrics so their line spacing is consistent across the super-family.

This is an experimental extended version of com.google.fonts/check/family/vertical_metrics and for now it will only result in WARNs.

Ensure indic fonts have the Indian Rupee Sign glyph.

Per Bureau of Indian Standards every font supporting one of the official Indian languages needs to include Unicode Character “₹” (U+20B9) Indian Rupee Sign.

Check font contains no unreachable glyphs

Glyphs are either accessible directly through Unicode codepoints or through substitution rules.

In Color Fonts, glyphs are also referenced by the COLR table.

Any glyphs not accessible by either of these means are redundant and serve only to increase the font's file size.

Check if each glyph has the recommended amount of contours.

Visually QAing thousands of glyphs by hand is tiring. Most glyphs can only be constructured in a handful of ways. This means a glyph's contour count will only differ slightly amongst different fonts, e.g a 'g' could either be 2 or 3 contours, depending on whether its double story or single story.

However, a quotedbl should have 2 contours, unless the font belongs to a display family.

This check currently does not cover variable fonts because there's plenty of alternative ways of constructing glyphs with multiple outlines for each feature in a VarFont. The expected contour count data for this check is currently optimized for the typical construction of glyphs in static fonts.

Does the font contain a soft hyphen?

The 'Soft Hyphen' character (codepoint 0x00AD) is used to mark a hyphenation possibility within a word in the absence of or overriding dictionary hyphenation.

It is sometimes designed empty with no width (such as a control character), sometimes the same as the traditional hyphen, sometimes double encoded with the hyphen.

That being said, it is recommended to not include it in the font at all, because discretionary hyphenation should be handled at the level of the shaping engine, not the font. Also, even if present, the software would not display that character.

More discussion at: https://typedrawers.com/discussion/2046/special-dash-things-softhyphen-horizontalbar

Does the font contain chws and vchw features?

The W3C recommends the addition of chws and vchw features to CJK fonts to enhance the spacing of glyphs in environments which do not fully support JLREQ layout rules.

The chws_tool utility (https://github.com/googlefonts/chws_tool) can be used to add these features automatically.

Ensure component transforms do not perform scaling or rotation.

Some families have glyphs which have been constructed by using transformed components e.g the 'u' being constructed from a flipped 'n'.

From a designers point of view, this sounds like a win (less work). However, such approaches can lead to rasterization issues, such as having the 'u' not sitting on the baseline at certain sizes after running the font through ttfautohint.

Other issues are outlines that end up reversed when only one dimension is flipped while the other isn't.

As of July 2019, Marc Foley observed that ttfautohint assigns cvt values to transformed glyphs as if they are not transformed and the result is they render very badly, and that vttLib does not support flipped components.

When building the font with fontmake, the problem can be fixed by adding this to the command line:

--filter DecomposeTransformedComponentsFilter

Ensure no GPOS7 lookups are present.

Versions of fonttools >=4.14.0 (19 August 2020) perform an optimisation on chained contextual lookups, expressing GSUB6 as GSUB5 and GPOS8 and GPOS7 where possible (when there are no suffixes/prefixes for all rules in the lookup).

However, makeotf has never generated these lookup types and they are rare in practice. Perhaps before of this, Mac's CoreText shaper does not correctly interpret GPOS7, meaning that these lookups will be ignored by the shaper, and fonts containing these lookups will have unintended positioning errors.

To fix this warning, rebuild the font with a recent version of fonttools.

Ensure that the font can be rasterized by FreeType.

Malformed fonts can cause FreeType to crash.

Font has the proper sfntVersion value?

OpenType fonts that contain TrueType outlines should use the value of 0x00010000 for the sfntVersion. OpenType fonts containing CFF data (version 1 or 2) should use 0x4F54544F ('OTTO', when re-interpreted as a Tag) for sfntVersion.

Fonts with the wrong sfntVersion value are rejected by FreeType.

https://docs.microsoft.com/en-us/typography/opentype/spec/otff#table-directory

Space and non-breaking space have the same width?

If the space and nbspace glyphs have different widths, then Google Workspace has problems with the font.

The nbspace is used to replace the space character in multiple situations in documents; such as the space before punctuation in languages that do that. It avoids the punctuation to be separated from the last word and go to next line.

This is automatic substitution by the text editors, not by fonts. It's also used by designers in text composition practice to create nicely shaped paragraphs. If the space and the nbspace are not the same width, it breaks the text composition of documents.

Detect any interpolation issues in the font.

When creating a variable font, the designer must make sure that corresponding paths have the same start points across masters, as well as that corresponding component shapes are placed in the same order within a glyph across masters. If this is not done, the glyph will not interpolate correctly.

Here we check for the presence of potential interpolation errors using the fontTools.varLib.interpolatable module.

Check math signs have the same width.

It is a common practice to have math signs sharing the same width (preferably the same width as tabular figures accross the entire font family).

This probably comes from the will to avoid additional tabular math signs knowing that their design can easily share the same width.

Checking Vertical Metric Linegaps.

The LineGap value is a space added to the line height created by the union of the (typo/hhea)Ascender and (typo/hhea)Descender. It is handled differently according to the environment.

This leading value will be added above the text line in most desktop apps. It will be shared above and under in web browsers, and ignored in Windows if Use_Typo_Metrics is disabled.

For better linespacing consistency across platforms, (typo/hhea)LineGap values must be 0.

Checking STAT table entries in static fonts.

Adobe feature syntax allows for the definition of a STAT table. Fonts built with a hand-coded STAT table in feature syntax may be built either as static or variable, but will end up with the same STAT table.

This is a problem, because a STAT table which works on variable fonts will not be appropriate for static instances. The examples in the OpenType spec of non-variable fonts with a STAT table show that the table entries must be restricted to those entries which refer to the static font's position in the designspace. i.e. a Regular weight static should only have the following entry for the weight axis:

However, if the STAT table intended for a variable font is compiled into a static, it will have many entries for this axis. In this case, Windows will read the first entry only, causing all instances to report themselves as "Thin Condensed".

Check accent of Lcaron, dcaron, lcaron, tcaron (derived from com.google.fonts/check/alt_caron)

Lcaron, dcaron, lcaron, tcaron should NOT be composed with quoteright or quotesingle or comma or caron(comb). It should be composed with a distinctive glyph which doesn't look like an apostrophe.

Source: https://ilovetypography.com/2009/01/24/on-diacritics/ http://diacritics.typo.cz/index.php?id=5 https://www.typotheque.com/articles/lcaron

Section: fontbakery.profiles.cff

Is the CFF subr/gsubr call depth > 10?

Per "The Type 2 Charstring Format, Technical Note #5177", the "Subr nesting, stack limit" is 10.

Is the CFF2 subr/gsubr call depth > 10?

Per "The CFF2 CharString Format", the "Subr nesting, stack limit" is 10.

Does the font use deprecated CFF operators or operations?

The 'dotsection' operator and the use of 'endchar' to build accented characters from the Adobe Standard Encoding Character Set ("seac") are deprecated in CFF. Adobe recommends repairing any fonts that use these, especially endchar-as-seac, because a rendering issue was discovered in Microsoft Word with a font that makes use of this operation. The check treats that usage as a FAIL. There are no known ill effects of using dotsection, so that check is a WARN.

Section: fontbakery.profiles.cmap

Fonts have equal unicode encodings?

Section: fontbakery.profiles.head

Make sure all font files have the same version value.

Checking unitsPerEm value is reasonable.

According to the OpenType spec:

The value of unitsPerEm at the head table must be a value between 16 and 16384. Any value in this range is valid.

In fonts that have TrueType outlines, a power of 2 is recommended as this allows performance optimizations in some rasterizers.

But 1000 is a commonly used value. And 2000 may become increasingly more common on Variable Fonts.

Checking font version fields (head and name table).

Checking head.macStyle value.

The values of the flags on the macStyle entry on the 'head' OpenType table that describe whether a font is bold and/or italic must be coherent with the actual style of the font as inferred by its filename.

Section: fontbakery.profiles.os2

Fonts have consistent PANOSE proportion?

Fonts have consistent PANOSE family type?

Check that OS/2.fsSelection bold & italic settings are unique for each NameID1

Per the OpenType spec: name ID 1 'is used in combination with Font Subfamily name (name ID 2), and should be shared among at most four fonts that differ only in weight or style.

This four-way distinction should also be reflected in the OS/2.fsSelection field, using bits 0 and 5.

Check if OS/2 xAvgCharWidth is correct.

Check if OS/2 fsSelection matches head macStyle bold and italic bits.

The bold and italic bits in OS/2.fsSelection must match the bold and italic bits in head.macStyle per the OpenType spec.

Check code page character ranges

At least some programs (such as Word and Sublime Text) under Windows 7 do not recognize fonts unless code page bits are properly set on the ulCodePageRange1 (and/or ulCodePageRange2) fields of the OS/2 table.

More specifically, the fonts are selectable in the font menu, but whichever Windows API these applications use considers them unsuitable for any character set, so anything set in these fonts is rendered with Arial as a fallback font.

This check currently does not identify which code pages should be set. Auto-detecting coverage is not trivial since the OpenType specification leaves the interpretation of whether a given code page is "functional" or not open to the font developer to decide.

So here we simply detect as a FAIL when a given font has no code page declared at all.

Checking OS/2 achVendID against configuration.

When a font project's Vendor ID is specified explicitly on FontBakery's configuration file, all binaries must have a matching vendor identifier value in the OS/2 table.

Checking OS/2 fsSelection value.

Section: fontbakery.profiles.post

Fonts have consistent underline thickness?

Dave C Lemon (Adobe Type Team) recommends setting the underline thickness to be consistent across the family.

If thicknesses are not family consistent, words set on the same line which have different styles look strange.

Font has correct post table version?

Format 2.5 of the 'post' table was deprecated in OpenType 1.3 and should not be used.

According to Thomas Phinney, the possible problem with post format 3 is that under the right combination of circumstances, one can generate PDF from a font with a post format 3 table, and not have accurate backing store for any text that has non-default glyphs for a given codepoint.

It will look fine but not be searchable. This can affect Latin text with high-end typography, and some complex script writing systems, especially with higher-quality fonts. Those circumstances generally involve creating a PDF by first printing a PostScript stream to disk, and then creating a PDF from that stream without reference to the original source document. There are some workflows where this applies,but these are not common use cases.

Apple recommends against use of post format version 4 as "no longer necessary and should be avoided". Please see the Apple TrueType reference documentation for additional details.

https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6post.html

Acceptable post format versions are 2 and 3 for TTF and OTF CFF2 builds, and post format 3 for CFF builds.

Checking post.italicAngle value. (derived from com.google.fonts/check/italic_angle)

The 'post' table italicAngle property should be a reasonable amount, likely not more than 30°. Note that in the OpenType specification, the value is negative for a rightward lean.

https://docs.microsoft.com/en-us/typography/opentype/spec/post

Section: fontbakery.profiles.name

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 [...]'

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."

https://learn.microsoft.com/en-us/typography/opentype/spec/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.

Check name table for empty records.

Check the name table for empty records, as this can cause problems in Adobe apps.

Description strings in the name table must not contain copyright info.

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 https://monotypecom-test.monotype.de/services/pan2)

• 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.

Source: https://typedrawers.com/discussion/comment/45140/#Comment_45140

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."

https://docs.microsoft.com/en-us/typography/opentype/otspec150/name#name-ids

PostScript name follows OpenType specification requirements?

Font follows the family naming recommendations?

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.

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.

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.

Section: fontbakery.profiles.loca

Does the number of glyphs in the loca table match the maxp table?

Section: fontbakery.profiles.hhea

MaxAdvanceWidth is consistent with values in the Hmtx and Hhea tables?

Check hhea.caretSlopeRise and hhea.caretSlopeRun

Checks whether hhea.caretSlopeRise and hhea.caretSlopeRun match with post.italicAngle.

For Upright fonts, you can set hhea.caretSlopeRise to 1 and hhea.caretSlopeRun to 0.

For Italic fonts, you can set hhea.caretSlopeRise to head.unitsPerEm and calculate hhea.caretSlopeRun like this: round(math.tan( math.radians(-1 * font["post"].italicAngle)) * font["head"].unitsPerEm)

This check allows for a 0.1° rounding difference between the Italic angle as calculated by the caret slope and post.italicAngle

Section: fontbakery.profiles.dsig

Does the font have a DSIG table?

Microsoft Office 2013 and below products expect fonts to have a digital signature declared in a DSIG table in order to implement OpenType features. The EOL date for Microsoft Office 2013 products is 4/11/2023. This issue does not impact Microsoft Office 2016 and above products.

As we approach the EOL date, it is now considered better to completely remove the table.

But if you still want your font to support OpenType features on Office 2013, then you may find it handy to add a fake signature on a placeholder DSIG table by running one of the helper scripts provided at https://github.com/googlefonts/gftools

Reference: https://github.com/fonttools/fontbakery/issues/1845

Section: fontbakery.profiles.gdef

Check glyphs in mark glyph class are non-spacing.

Glyphs in the GDEF mark glyph class should be non-spacing.

Spacing glyphs in the GDEF mark glyph class may have incorrect anchor positioning that was only intended for building composite glyphs during design.

Check mark characters are in GDEF mark glyph class.

Mark characters should be in the GDEF mark glyph class.

Check GDEF mark glyph class doesn't have characters that are not marks.

Glyphs in the GDEF mark glyph class become non-spacing and may be repositioned if they have mark anchors.

Only combining mark glyphs should be in that class. Any non-mark glyph must not be in that class, in particular spacing glyphs.

Section: fontbakery.profiles.gpos

Does GPOS table have kerning information? This check skips monospaced fonts as defined by post.isFixedPitch value

Section: fontbakery.profiles.kern

Is there a usable "kern" table declared in the font?

Even though all fonts should have their kerning implemented in the GPOS table, there may be kerning info at the kern table as well.

Some applications such as MS PowerPoint require kerning info on the kern table. More specifically, they require a format 0 kern subtable from a kern table version 0 with only glyphs defined in the cmap table, which is the only one that Windows understands (and which is also the simplest and more limited of all the kern subtables).

Google Fonts ingests fonts made for download and use on desktops, and does all web font optimizations in the serving pipeline (using libre libraries that anyone can replicate.)

Ideally, TTFs intended for desktop users (and thus the ones intended for Google Fonts) should have both KERN and GPOS tables.

Given all of the above, we currently treat kerning on a v0 kern table as a good-to-have (but optional) feature.

Section: fontbakery.profiles.glyf

Is there any unused data at the end of the glyf table?

Check for points out of bounds.

Check glyphs do not have duplicate components which have the same x,y coordinates.

There have been cases in which fonts had faulty double quote marks, with each of them containing two single quote marks as components with the same x, y coordinates which makes them visually look like single quote marks.

This check ensures that glyphs do not contain duplicate components which have the same x,y coordinates.

Section: fontbakery.profiles.fvar

The variable font 'wght' (Weight) axis coordinate must be 400 on the 'Regular' instance.

According to the Open-Type spec's registered design-variation tag 'wght' available at https://docs.microsoft.com/en-gb/typography/opentype/spec/dvaraxistag_wght

If a variable font has a 'wght' (Weight) axis, then the coordinate of its 'Regular' instance is required to be 400.

The variable font 'wdth' (Width) axis coordinate must be 100 on the 'Regular' instance.

According to the Open-Type spec's registered design-variation tag 'wdth' available at https://docs.microsoft.com/en-gb/typography/opentype/spec/dvaraxistag_wdth

If a variable font has a 'wdth' (Width) axis, then the coordinate of its 'Regular' instance is required to be 100.

The variable font 'slnt' (Slant) axis coordinate must be zero on the 'Regular' instance.

According to the Open-Type spec's registered design-variation tag 'slnt' available at https://docs.microsoft.com/en-gb/typography/opentype/spec/dvaraxistag_slnt

If a variable font has a 'slnt' (Slant) axis, then the coordinate of its 'Regular' instance is required to be zero.

The variable font 'ital' (Italic) axis coordinate must be zero on the 'Regular' instance.

According to the Open-Type spec's registered design-variation tag 'ital' available at https://docs.microsoft.com/en-gb/typography/opentype/spec/dvaraxistag_ital

If a variable font has a 'ital' (Italic) axis, then the coordinate of its 'Regular' instance is required to be zero.

The variable font 'opsz' (Optical Size) axis coordinate should be between 10 and 16 on the 'Regular' instance.

According to the Open-Type spec's registered design-variation tag 'opsz' available at https://docs.microsoft.com/en-gb/typography/opentype/spec/dvaraxistag_opsz

If a variable font has an 'opsz' (Optical Size) axis, then the coordinate of its 'Regular' instance is recommended to be a value in the range 10 to 16.

The variable font 'wght' (Weight) axis coordinate must be 700 on the 'Bold' instance.

The Open-Type spec's registered design-variation tag 'wght' available at https://docs.microsoft.com/en-gb/typography/opentype/spec/dvaraxistag_wght does not specify a required value for the 'Bold' instance of a variable font.

But Dave Crossland suggested that we should enforce a required value of 700 in this case (NOTE: a distinction is made between "no bold instance present" vs "bold instance is present but its wght coordinate is not == 700").

The variable font 'wght' (Weight) axis coordinate must be within spec range of 1 to 1000 on all instances.

According to the Open-Type spec's registered design-variation tag 'wght' available at https://docs.microsoft.com/en-gb/typography/opentype/spec/dvaraxistag_wght

On the 'wght' (Weight) axis, the valid coordinate range is 1-1000.

The variable font 'wdth' (Width) axis coordinate must strictly greater than zero.

According to the Open-Type spec's registered design-variation tag 'wdth' available at https://docs.microsoft.com/en-gb/typography/opentype/spec/dvaraxistag_wdth

On the 'wdth' (Width) axis, the valid numeric range is strictly greater than zero.

The variable font 'slnt' (Slant) axis coordinate specifies positive values in its range?

The OpenType spec says at https://docs.microsoft.com/en-us/typography/opentype/spec/dvaraxistag_slnt that:

[...] the scale for the Slant axis is interpreted as the angle of slant in counter-clockwise degrees from upright. This means that a typical, right-leaning oblique design will have a negative slant value. This matches the scale used for the italicAngle field in the post table.

Validates that the value of axisNameID used by each VariationAxisRecord is greater than 255 and less than 32768.

According to the 'fvar' documentation in OpenType spec v1.9 https://docs.microsoft.com/en-us/typography/opentype/spec/fvar

The axisNameID field provides a name ID that can be used to obtain strings from the 'name' table that can be used to refer to the axis in application user interfaces. The name ID must be greater than 255 and less than 32768.

Validates that the value of subfamilyNameID used by each InstanceRecord is 2, 17, or greater than 255 and less than 32768.

According to the 'fvar' documentation in OpenType spec v1.9 https://docs.microsoft.com/en-us/typography/opentype/spec/fvar

The subfamilyNameID field provides a name ID that can be used to obtain strings from the 'name' table that can be treated as equivalent to name ID 17 (typographic subfamily) strings for the given instance. Values of 2 or 17 can be used; otherwise, values must be greater than 255 and less than 32768.

Validates that the value of postScriptNameID used by each InstanceRecord is 6, 0xFFFF, or greater than 255 and less than 32768.

According to the 'fvar' documentation in OpenType spec v1.9 https://docs.microsoft.com/en-us/typography/opentype/spec/fvar

The postScriptNameID field provides a name ID that can be used to obtain strings from the 'name' table that can be treated as equivalent to name ID 6 (PostScript name) strings for the given instance. Values of 6 and 0xFFFF can be used; otherwise, values must be greater than 255 and less than 32768.

Validates that when an instance record is included for the default instance, its subfamilyNameID value is set to a name ID whose string is equal to the string of either name ID 2 or 17, and its postScriptNameID value is set to a name ID whose string is equal to the string of name ID 6.

According to the 'fvar' documentation in OpenType spec v1.9.1 https://docs.microsoft.com/en-us/typography/opentype/spec/fvar

The default instance of a font is that instance for which the coordinate value of each axis is the defaultValue specified in the corresponding variation axis record. An instance record is not required for the default instance, though an instance record can be provided. When enumerating named instances, the default instance should be enumerated even if there is no corresponding instance record. If an instance record is included for the default instance (that is, an instance record has coordinates set to default values), then the nameID value should be set to either 2 or 17 or to a name ID with the same value as name ID 2 or 17. Also, if a postScriptNameID is included in instance records, and the postScriptNameID value should be set to 6 or to a name ID with the same value as name ID 6.

Validates that all of the instance records in a given font have the same size.

According to the 'fvar' documentation in OpenType spec v1.9 https://docs.microsoft.com/en-us/typography/opentype/spec/fvar

All of the instance records in a given font must be the same size, with all either including or omitting the postScriptNameID field. [...] If the value is 0xFFFF, then the value is ignored, and no PostScript name equivalent is provided for the instance.

Validates that all of the instance records in a given font have distinct data.

According to the 'fvar' documentation in OpenType spec v1.9 https://docs.microsoft.com/en-us/typography/opentype/spec/fvar

All of the instance records in a font should have distinct coordinates and distinct subfamilyNameID and postScriptName ID values. If two or more records share the same coordinates, the same nameID values or the same postScriptNameID values, then all but the first can be ignored.

Validate foundry-defined design-variation axis tag names.

According to the Open-Type spec's syntactic requirements for foundry-defined design-variation axis tags available at https://learn.microsoft.com/en-us/typography/opentype/spec/dvaraxisreg

Foundry-defined tags must begin with an uppercase letter and must use only uppercase letters or digits.

Section: fontbakery.profiles.stat

Ensure VFs have 'ital' STAT axis.

Check that related Upright and Italic VFs have a 'ital' axis in STAT table.

All fvar axes have a correspondent Axis Record on STAT table?

According to the OpenType spec, there must be an Axis Record for every axis defined in the fvar table.

https://docs.microsoft.com/en-us/typography/opentype/spec/stat#axis-records

STAT table has Axis Value tables?

According to the OpenType spec, in a variable font, it is strongly recommended that axis value tables be included for every element of typographic subfamily names for all of the named instances defined in the 'fvar' table.

Axis value tables are particularly important for variable fonts, but can also be used in non-variable fonts. When used in non-variable fonts, axis value tables for particular values should be implemented consistently across fonts in the family.

If present, Format 4 Axis Value tables are checked to ensure they have more than one AxisValueRecord (a strong recommendation from the OpenType spec).

https://docs.microsoft.com/en-us/typography/opentype/spec/stat#axis-value-tables

Ensure 'ital' STAT axis is boolean value (derived from com.google.fonts/check/italic_axis_in_stat_is_boolean)

Check that the value of the 'ital' STAT axis is boolean (either 0 or 1), and elided for the Upright and not elided for the Italic, and that the Upright is linked to the Italic.

Ensure 'ital' STAT axis is last. (derived from com.google.fonts/check/italic_axis_last)

Check that the 'ital' STAT axis is last in axis order.

Section: fontbakery.profiles.layout

Does the font have any invalid feature tags?

Incorrect tags can be indications of typos, leftover debugging code or questionable approaches, or user error in the font editor. Such typos can cause features and language support to fail to work as intended.

Does the font have any invalid script tags?

Incorrect script tags can be indications of typos, leftover debugging code or questionable approaches, or user error in the font editor. Such typos can cause features and language support to fail to work as intended.

Does the font have any invalid language tags?

Incorrect language tags can be indications of typos, leftover debugging code or questionable approaches, or user error in the font editor. Such typos can cause features and language support to fail to work as intended.

Section: Outline Correctness Checks

Are there any misaligned on-curve points?

This check heuristically looks for on-curve points which are close to, but do not sit on, significant boundary coordinates. For example, a point which has a Y-coordinate of 1 or -1 might be a misplaced baseline point. As well as the baseline, here we also check for points near the x-height (but only for lowercase Latin letters), cap-height, ascender and descender Y coordinates.

Not all such misaligned curve points are a mistake, and sometimes the design may call for points in locations near the boundaries. As this check is liable to generate significant numbers of false positives, it will pass if there are more than 100 reported misalignments.

Are any segments inordinately short?

This check looks for outline segments which seem particularly short (less than 0.6% of the overall path length).

This check is not run for variable fonts, as they may legitimately have short segments. As this check is liable to generate significant numbers of false positives, it will pass if there are more than 100 reported short segments.

Do any segments have colinear vectors?

This check looks for consecutive line segments which have the same angle. This normally happens if an outline point has been added by accident.

This check is not run for variable fonts, as they may legitimately have colinear vectors.

Do outlines contain any jaggy segments?

This check heuristically detects outline segments which form a particularly small angle, indicative of an outline error. This may cause false positives in cases such as extreme ink traps, so should be regarded as advisory and backed up by manual inspection.

Do outlines contain any semi-vertical or semi-horizontal lines?

This check detects line segments which are nearly, but not quite, exactly horizontal or vertical. Sometimes such lines are created by design, but often they are indicative of a design error.

This check is disabled for italic styles, which often contain nearly-upright lines.

Section: Shaping Checks

Check that texts shape as per expectation

Fonts with complex layout rules can benefit from regression tests to ensure that the rules are behaving as designed. This checks runs a shaping test suite and compares expected shaping against actual shaping, reporting any differences.

Shaping test suites should be written by the font engineer and referenced in the FontBakery configuration file. For more information about write shaping test files and how to configure FontBakery to read the shaping test suites, see https://simoncozens.github.io/tdd-for-otl/

Check that no forbidden glyphs are found while shaping

Fonts with complex layout rules can benefit from regression tests to ensure that the rules are behaving as designed. This checks runs a shaping test suite and reports if any glyphs are generated in the shaping which should not be produced. (For example, .notdef glyphs, visible viramas, etc.)

Shaping test suites should be written by the font engineer and referenced in the FontBakery configuration file. For more information about write shaping test files and how to configure FontBakery to read the shaping test suites, see https://simoncozens.github.io/tdd-for-otl/

Check that no collisions are found while shaping

Fonts with complex layout rules can benefit from regression tests to ensure that the rules are behaving as designed. This checks runs a shaping test suite and reports instances where the glyphs collide in unexpected ways.

Shaping test suites should be written by the font engineer and referenced in the FontBakery configuration file. For more information about write shaping test files and how to configure FontBakery to read the shaping test suites, see https://simoncozens.github.io/tdd-for-otl/

Ensure dotted circle glyph is present and can attach marks.

The dotted circle character (U+25CC) is inserted by shaping engines before mark glyphs which do not have an associated base, especially in the context of broken syllabic clusters.

For fonts containing combining marks, it is recommended that the dotted circle character be included so that these isolated marks can be displayed properly; for fonts supporting complex scripts, this should be considered mandatory.

Additionally, when a dotted circle glyph is present, it should be able to display all marks correctly, meaning that it should contain anchors for all attaching marks.