universal

FontBakeryCondition fontbakery.profiles.universal.STAT_table[source][source]
force = False[source]
com.google.fonts/check/STAT_strings[source][source]

Check correctness of STAT table strings

Rationale:

On the STAT table, the “Italic” keyword must not be used on AxisValues for variation axes other than ‘ital’.

com.google.fonts/check/family/single_directory[source][source]

Checking all files are in the same directory.

Rationale:

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

com.google.fonts/check/family/vertical_metrics[source][source]

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

Rationale:

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

com.google.fonts/check/family/win_ascent_and_descent[source][source]

Checking OS/2 usWinAscent & usWinDescent.

Rationale:

A font’s winAscent and winDescent values should be greater than 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 abs(yMin) 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 abs(yMin).

com.google.fonts/check/fontbakery_version[source][source]

Do we have the latest version of FontBakery installed?

com.google.fonts/check/ftxvalidator[source][source]

Checking with ftxvalidator.

com.google.fonts/check/ftxvalidator_is_available[source][source]

Is the command ftxvalidator (Apple Font Tool Suite) available?

Rationale:

There’s no reasonable (and legal) way to run the command ftxvalidator of the Apple Font Tool Suite on a non-macOS machine. I.e. on GNU+Linux or Windows etc.

If Font Bakery is not running on an OSX machine, the machine running Font Bakery could access ftxvalidator on OSX, e.g. via ssh or a remote procedure call (rpc).

There’s an ssh example implementation at: https://github.com/googlefonts/fontbakery/blob/master/prebuilt/workarounds/ftxvalidator/ssh-implementation/ftxvalidator

com.google.fonts/check/mandatory_glyphs[source][source]

Font contains .notdef as first glyph?

Rationale:

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

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

Pre-v1.8, it was recommended that a font should also contain a .null, CR and space glyph. This might have been relevant for applications on MacOS 9.

com.google.fonts/check/name/trailing_spaces[source][source]

Name table records must not have trailing spaces.

com.google.fonts/check/os2_metrics_match_hhea[source][source]

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.

Rationale:

When OS/2 and hhea vertical metrics match, the same linespacing results on macOS, GNU+Linux and Windows. Unfortunately as of 2018, Google Fonts has released many fonts with vertical metrics that don’t match in this way. When we fix this issue in these existing families, we will create a visible change in line/paragraph layout for either Windows or macOS users, which will upset some of them.

But we have a duty to fix broken stuff, and inconsistent paragraph layout is unacceptably broken when it is possible to avoid it.

If users complain and prefer the old broken version, they have the freedom to take care of their own situation.

com.google.fonts/check/ots[source][source]

Checking with ots-sanitize.

com.google.fonts/check/required_tables[source][source]

Font contains all required tables?

Rationale:

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. A DSIG table containing a digital signature helps ensure the integrity of the font file. Etc.

com.google.fonts/check/superfamily/list[source][source]

List all superfamily filepaths

Rationale:

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.

com.google.fonts/check/superfamily/vertical_metrics[source][source]

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

Rationale:

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/superfamily/vertical_metrics and for now it will only result in WARNs.

com.google.fonts/check/ttx-roundtrip[source][source]

Checking with fontTools.ttx

com.google.fonts/check/unique_glyphnames[source][source]

Font contains unique glyph names?

Rationale:

Duplicate glyph names prevent font installation on Mac OS X.

com.google.fonts/check/unwanted_tables[source][source]

Are there unwanted tables?

Rationale:

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.

com.google.fonts/check/valid_glyphnames[source][source]

Glyph names are all valid?

Rationale:

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

com.google.fonts/check/whitespace_glyphnames[source][source]

Font has proper whitespace glyph names?

com.google.fonts/check/whitespace_glyphs[source][source]

Font contains glyphs for whitespace characters?

com.google.fonts/check/whitespace_ink[source][source]

Whitespace glyphs have ink?

FontBakeryCondition fontbakery.profiles.universal.ftxvalidator_cmd[source][source]

Test if ftxvalidator is a command; i.e. an executable with a path.

force = False[source]
fontbakery.profiles.universal.is_up_to_date(installed, latest)[source][source]