googlefonts

com.google.fonts/check/STAT/axis_order

Check axis ordering on the STAT table.

Rationale:

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.

com.google.fonts/check/STAT/gf-axisregistry

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

Rationale:

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/master/axisregistry

com.google.fonts/check/aat

Are there unwanted Apple tables?

Rationale:

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/

com.google.fonts/check/canonical_filename

Checking file is named canonically.

Rationale:

A font’s filename must be composed in the following manner: <familyname>-<stylename>.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

com.google.fonts/check/cjk_vertical_metrics

Check font follows the Google Fonts CJK vertical metric schema

Rationale:

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/master/Spec#cjk-vertical-metrics

com.google.fonts/check/contour_count

Check if each glyph has the recommended amount of contours.

This check is useful to assure glyphs aren’t incorrectly constructed.

The desired_glyph_data module contains the ‘recommended’ countour count for encoded glyphs. The contour counts are derived from fonts which were chosen for their quality and unique design decisions for particular glyphs.

In the future, additional glyph data can be included. A good addition would be the ‘recommended’ anchor counts for each glyph.

Rationale:

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.

com.google.fonts/check/description/broken_links

Does DESCRIPTION file contain broken links?

Rationale:

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.

com.google.fonts/check/description/eof_linebreak

DESCRIPTION.en_us.html should end in a linebreak.

Rationale:

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 char on them.

com.google.fonts/check/description/git_url

Does DESCRIPTION file contain a upstream Git repo URL?

Rationale:

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.

com.google.fonts/check/description/max_length

DESCRIPTION.en_us.html must have less than 1000 bytes.

com.google.fonts/check/description/min_length

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

com.google.fonts/check/description/valid_html

Is this a proper HTML snippet?

Rationale:

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 dummy description file which contains invalid html. This file needs to either be replaced with an existing description file or edited by hand.

com.google.fonts/check/epar

EPAR table present in font?

Rationale:

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/

com.google.fonts/check/family/control_chars

Does font file include unacceptable control character glyphs?

Rationale:

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.

com.google.fonts/check/family/has_license

Check font has a license.

com.google.fonts/check/family/tnum_horizontal_metrics

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

Rationale:

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

com.google.fonts/check/font_copyright

Copyright notices match canonical pattern in fonts

com.google.fonts/check/fontdata_namecheck

Familyname must be unique according to namecheck.fontdata.com

Rationale:

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

com.google.fonts/check/fontv

Check for font-v versioning.

Rationale:

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 a WARN if a given font does not yet follow the experimental versioning style, but at some point we may start enforcing it.

com.google.fonts/check/fsselection

Checking OS/2 fsSelection value.

com.google.fonts/check/fstype

Checking OS/2 fsType does not impose restrictions.

Rationale:

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

com.google.fonts/check/fvar_name_entries

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

Rationale:

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

com.google.fonts/check/gasp

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

Rationale:

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.

com.google.fonts/check/metadata/gf-axisregistry_bounds

Validate METADATA.pb axes values are within gf-axisregistry bounds.

Rationale:

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/master/axisregistry

com.google.fonts/check/gf-axisregistry/fvar_axis_defaults

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

Rationale:

Check that axis defaults have a corresponding fallback name registered at the Google Fonts Axis Registry, available at https://github.com/google/fonts/tree/master/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.

com.google.fonts/check/metadata/gf-axisregistry_valid_tags

Validate METADATA.pb axes tags are defined in gf-axisregistry.

Rationale:

Ensure all axes in a METADATA.pb file are registered in the Google Fonts Axis Registry, available at https://github.com/google/fonts/tree/master/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.

com.google.fonts/check/glyph_coverage

Check Google Fonts Latin Core glyph coverage.

Rationale:

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

com.google.fonts/check/has_ttfautohint_params

Font has ttfautohint params?

com.google.fonts/check/hinting_impact

Show hinting filesize impact.

Rationale:

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

com.google.fonts/check/integer_ppem_if_hinted

PPEM must be an integer on hinted fonts.

Rationale:

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;

com.google.fonts/check/italic_angle

Checking post.italicAngle value.

Rationale:

The ‘post’ table italicAngle property should be a reasonable amount, likely not more than -20°, never more than -30°, and never greater than 0°. Note that in the OpenType specification, the value is negative for a lean rightwards.

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

com.google.fonts/check/kerning_for_non_ligated_sequences

Is there kerning info for non-ligated sequences?

Rationale:

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

com.google.fonts/check/license/OFL_copyright

Check license file has good copyright string.

Rationale:

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)”

com.google.fonts/check/ligature_carets

Are there caret positions declared for every ligature?

Rationale:

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, ligature carets can be set directly on canvas by accessing the Glyph -> Set Anchors menu option or by pressing the Cmd+U keyboard shortcut.

If designing with UFOs, (as of Oct 2020) ligature carets are not yet compiled by ufo2ft, and therefore will not build via FontMake. See googlefonts/ufo2ft/issues/329

com.google.fonts/check/mac_style

Checking head.macStyle value.

Rationale:

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.

com.google.fonts/check/mandatory_avar_table

Ensure variable fonts include an avar table.

Rationale:

All high quality variable fonts 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.

com.google.fonts/check/metadata/broken_links

Does METADATA.pb copyright field contain broken links?

com.google.fonts/check/metadata/canonical_style_names

METADATA.pb: Font styles are named canonically?

com.google.fonts/check/metadata/canonical_weight_value

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

com.google.fonts/check/metadata/category

Ensure METADATA.pb category field is valid.

Rationale:

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.

com.google.fonts/check/metadata/consistent_axis_enumeration

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

Rationale:

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.

com.google.fonts/check/metadata/copyright

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

com.google.fonts/check/metadata/copyright_max_length

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

com.google.fonts/check/metadata/designer_profiles

METADATA.pb: Designer is listed with the correct name on the Google Fonts catalog of designers?

com.google.fonts/check/metadata/designer_values

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

Rationale:

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

com.google.fonts/check/metadata/escaped_strings

Ensure METADATA.pb does not use escaped strings.

Rationale:

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.

com.google.fonts/check/metadata/familyname

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

com.google.fonts/check/metadata/filenames

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

Rationale:

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.

com.google.fonts/check/metadata/fontname_not_camel_cased

METADATA.pb: Check if fontname is not camel cased.

com.google.fonts/check/metadata/has_regular

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

com.google.fonts/check/metadata/includes_production_subsets

Check METADATA.pb includes production subsets.

Rationale:

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

com.google.fonts/check/metadata/italic_style

METADATA.pb font.style “italic” matches font internals?

com.google.fonts/check/metadata/license

METADATA.pb license is “APACHE2”, “UFL” or “OFL”?

com.google.fonts/check/metadata/listed_on_gfonts

METADATA.pb: Fontfamily is listed on Google Fonts API?

com.google.fonts/check/metadata/match_filename_postscript

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

com.google.fonts/check/metadata/match_fullname_postscript

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

com.google.fonts/check/metadata/match_name_familyname

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

com.google.fonts/check/metadata/match_weight_postscript

METADATA.pb weight matches postScriptName for static fonts.

com.google.fonts/check/metadata/menu_and_latin

METADATA.pb should contain at least “menu” and “latin” subsets.

com.google.fonts/check/metadata/multiple_designers

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

Rationale:

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.

com.google.fonts/check/metadata/nameid/copyright

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

com.google.fonts/check/metadata/nameid/family_and_full_names

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

com.google.fonts/check/metadata/nameid/family_name

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

com.google.fonts/check/metadata/nameid/font_name

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

com.google.fonts/check/metadata/nameid/full_name

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

com.google.fonts/check/metadata/nameid/post_script_name

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

com.google.fonts/check/metadata/normal_style

METADATA.pb font.style “normal” matches font internals?

com.google.fonts/check/metadata/os2_weightclass

Check METADATA.pb font weights are correct.

Rationale:

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.

com.google.fonts/check/metadata/parses

Check METADATA.pb parse correctly.

Rationale:

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

com.google.fonts/check/metadata/regular_is_400

METADATA.pb: Regular should be 400.

com.google.fonts/check/metadata/reserved_font_name

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

com.google.fonts/check/metadata/subsets_order

METADATA.pb subsets should be alphabetically ordered.

com.google.fonts/check/metadata/undeclared_fonts

Ensure METADATA.pb lists all font binaries.

Rationale:

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.

com.google.fonts/check/metadata/unique_full_name_values

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

com.google.fonts/check/metadata/unique_weight_style_pairs

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

com.google.fonts/check/metadata/unknown_designer

Font designer field in METADATA.pb must not be ‘unknown’.

com.google.fonts/check/metadata/valid_copyright

Copyright notices match canonical pattern in METADATA.pb

Rationale:

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 <familyname> 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)”

com.google.fonts/check/metadata/valid_filename_values

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

com.google.fonts/check/metadata/valid_full_name_values

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

com.google.fonts/check/metadata/valid_name_values

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

com.google.fonts/check/metadata/valid_post_script_name_values

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

com.google.fonts/check/name/ascii_only_entries

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

Rationale:

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.

com.google.fonts/check/name/copyright_length

Length of copyright notice must not exceed 500 characters.

Rationale:

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.

com.google.fonts/check/name/description_max_length

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

Rationale:

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.

com.google.fonts/check/name/family_and_style_max_length

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

Rationale:

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/googlefonts/fontbakery/issues/2179

com.google.fonts/check/name/familyname

Check name table: FONT_FAMILY_NAME entries.

Rationale:

Checks that the family name infered from the font filename matches the string at nameID 1 (NAMEID_FONT_FAMILY_NAME) if it conforms to RIBBI and otherwise checks that nameID 1 is the family name + the style name.

com.google.fonts/check/name/familyname_first_char

Make sure family name does not begin with a digit.

Rationale:

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

com.google.fonts/check/name/fullfontname

Check name table: FULL_FONT_NAME entries.

com.google.fonts/check/name/license

Check copyright namerecords match license file.

Rationale:

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.

com.google.fonts/check/name/license_url

License URL matches License text on name table?

Rationale:

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.

com.google.fonts/check/name/line_breaks

Name table entries should not contain line-breaks.

Rationale:

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

com.google.fonts/check/name/mandatory_entries

Font has all mandatory ‘name’ table entries?

com.google.fonts/check/name/postscriptname

Check name table: POSTSCRIPT_NAME entries.

com.google.fonts/check/name/rfn

Name table strings must not contain the string ‘Reserved Font Name’.

Rationale:

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.

com.google.fonts/check/name/subfamilyname

Check name table: FONT_SUBFAMILY_NAME entries.

com.google.fonts/check/name/typographicfamilyname

Check name table: TYPOGRAPHIC_FAMILY_NAME entries.

com.google.fonts/check/name/typographicsubfamilyname

Check name table: TYPOGRAPHIC_SUBFAMILY_NAME entries.

com.google.fonts/check/name/unwanted_chars

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

com.google.fonts/check/name/version_format

Version format is correct in ‘name’ table?

com.google.fonts/check/old_ttfautohint

Font has old ttfautohint applied?

Rationale:

This check finds which version of ttfautohint was used, by inspecting name table entries and then finds which version of ttfautohint is currently installed in the system.

com.google.fonts/check/production_glyphs_similarity

Glyphs are similiar to Google Fonts version?

com.google.fonts/check/repo/dirname_matches_nameid_1

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

com.google.fonts/check/repo/fb_report

A font repository should not include fontbakery report files

Rationale:

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.

com.google.fonts/check/repo/vf_has_static_fonts

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

Rationale:

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.

com.google.fonts/check/repo/zip_files

A font repository should not include ZIP files

Rationale:

Sometimes people check in ZIPs into their font project repositories. While we accept the practice of checking in binaries, we believe that a ZIP is a step too far ;)

Note: a source purist position is that only source files and build scripts should be checked in.

com.google.fonts/check/smart_dropout

Font enables smart dropout control in “prep” table instructions?

Rationale:

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.

com.google.fonts/check/unitsperem_strict

Stricter unitsPerEm criteria for Google Fonts.

Rationale:

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.

com.google.fonts/check/usweightclass

Checking OS/2 usWeightClass.

Rationale:

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.

com.google.fonts/check/varfont/consistent_axes

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

Rationale:

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.

com.google.fonts/check/varfont_duplicate_instance_names

Check variable font instances don’t have duplicate names

Rationale:

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.

com.google.fonts/check/varfont/generate_static

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

Rationale:

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

com.google.fonts/check/varfont/has_HVAR

Check that variable fonts have an HVAR table.

Rationale:

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

com.google.fonts/check/varfont_has_instances

A variable font must have named instances.

Rationale:

Named instances must be present in all variable fonts in order not to frustrate the users’ typical expectations of a traditional static font workflow.

com.google.fonts/check/varfont_instance_coordinates

Check variable font instances have correct coordinate values

com.google.fonts/check/varfont_instance_names

Check variable font instances have correct names

com.google.fonts/check/varfont/unsupported_axes

Ensure VFs do not contain slnt or ital axes.

Rationale:

The ‘ital’ and ‘slnt’ axes are not supported yet in Google Chrome.

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

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

com.google.fonts/check/varfont_weight_instances

Variable font weight coordinates must be multiples of 100.

Rationale:

The named instances on the weight axis of a variable font must have coordinates that are multiples of 100 on the design space.

com.google.fonts/check/vendor_id

Checking OS/2 achVendID.

Rationale:

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.

com.google.fonts/check/version_bump

Version number has increased since previous release on Google Fonts?

com.google.fonts/check/vertical_metrics_regressions

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

Rationale:

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 Fontbakery 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/googlefonts/fontbakery/issues/1162

com.google.fonts/check/vttclean

There must not be VTT Talk sources in the font.

Rationale:

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.

FontBakeryCondition fontbakery.profiles.googlefonts.description_html

force = False