universal

The checks on the universal profile, documented below, evaluate adherence to the best practices shared among the type design community. Additionally, it also includes the checks from the opentype profile.

com.adobe.fonts/check/freetype_rasterizer[source][source]

Ensure that the font can be rasterized by FreeType.

Rationale:

Malformed fonts can cause FreeType to crash.

com.adobe.fonts/check/sfnt_version[source][source]

Font has the proper sfntVersion value?

Rationale:

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

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

Checking STAT table entries in static fonts.

Rationale:

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:

<AxisIndex value=”0”/> <Flags value=”2”/> <!– ElidableAxisValueName –> <ValueNameID value=”265”/> <!– Regular –> <Value value=”400.0”/>

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

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/alt_caron[source][source]

Check accent of Lcaron, dcaron, lcaron, tcaron

Rationale:

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

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

Check that glyph for U+0675 ARABIC LETTER HIGH HAMZA is not a mark.

Rationale:

Many fonts incorrectly treat ARABIC LETTER HIGH HAMZA (U+0675) as a variant of ARABIC HAMZA ABOVE (U+0654) and make it a combining mark of the same size.

But U+0675 is a base letter and should be a variant of ARABIC LETTER HAMZA (U+0621) but raised slightly above baseline.

Not doing so effectively makes the font useless for Jawi and possibly Kazakh as well.

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

Check that Arabic spacing symbols U+FBB2–FBC1 aren’t classified as marks.

Rationale:

Unicode has a few spacing symbols representing Arabic dots and other marks, but they are purposefully not classified as marks.

Many fonts mistakenly classify them as marks, making them unsuitable for their original purpose as stand-alone symbols to used in pedagogical contexts discussing Arabic consonantal marks.

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

Does the font contain chws and vchw features?

Rationale:

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.

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

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.

Legacy check originally simply called ‘check/153’. We used to lack richer metadata back in 2015. We’re open to further improvements to this description.

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

Legacy check originally simply called ‘check/002’. We used to lack richer metadata back in 2015. We’re open to further improvements to this description.

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

Legacy check originally simply called ‘check/040’. We used to lack richer metadata back in 2015. We’re open to further improvements to this description.

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

Do we have the latest version of FontBakery installed?

Rationale:

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.

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

Ensure no GPOS7 lookups are present.

Rationale:

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

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

Detect any interpolation issues in the font.

Rationale:

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.

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

Check that legacy accents aren’t used in composite glyphs.

Rationale:

Legacy accents should not be used in accented glyphs. The use of legacy accents in accented glyphs breaks the mark to mark combining feature that allows a font to stack diacritics over one glyph. Use combining marks instead as a component in composite glyphs.

Legacy accents should not have anchors and should have non-zero width. They are often used independently of a letter, either as a placeholder for an expected combined mark+letter combination in MacOS, or separately. For instance, U+00B4 (ACUTE ACCENT) is often mistakenly used as an apostrophe, U+0060 (GRAVE ACCENT) is used in Markdown to notify code blocks, and ^ is used as an exponential operator in maths.

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

Checking Vertical Metric Linegaps.

Rationale:

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.

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

Font contains ‘.notdef’ as its 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:

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.

Legacy check originally simply called ‘check/046’. We used to lack richer metadata back in 2015. We’re open to further improvements to this description.

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

Check math signs have the same width.

Rationale:

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.

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.

Rationale:

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.

Legacy check originally simply called ‘check/042’. We used to lack richer metadata back in 2015. We’re open to further improvements to this description.

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

Checking with ots-sanitize.

Legacy check originally simply called ‘check/036’. We used to lack richer metadata back in 2015. We’re open to further improvements to this description.

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

Font contains all required tables?

Rationale:

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.

Legacy check originally simply called ‘check/052’. We used to lack richer metadata back in 2015. We’re open to further improvements to this description.

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

Ensure indic fonts have the Indian Rupee Sign glyph.

Rationale:

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

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

Does the font contain a soft hyphen?

Rationale:

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

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

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

Ensure component transforms do not perform scaling or rotation.

Rationale:

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

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.

Legacy check originally simply called ‘check/059’. We used to lack richer metadata back in 2015. We’re open to further improvements to this description.

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

Check font contains no unreachable glyphs

Rationale:

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.

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.

Legacy check originally simply called ‘check/053’. We used to lack richer metadata back in 2015. We’re open to further improvements to this description.

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

Legacy check originally simply called ‘check/058’. We used to lack richer metadata back in 2015. We’re open to further improvements to this description. - Some additional changes were proposed at https://github.com/fonttools/fontbakery/issues/2832

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

Font has proper whitespace glyph names?

Rationale:

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

Legacy check originally simply called ‘check/048’. We used to lack richer metadata back in 2015. We’re open to further improvements to this description.

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

Font contains glyphs for whitespace characters?

Legacy check originally simply called ‘check/047’. We used to lack richer metadata back in 2015. We’re open to further improvements to this description.

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

Whitespace glyphs have ink?

Legacy check originally simply called ‘check/049’. We used to lack richer metadata back in 2015. We’re open to further improvements to this description.

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

Space and non-breaking space have the same width?

Rationale:

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.

Legacy check originally simply called ‘check/050’. We used to lack richer metadata back in 2015. We’re open to further improvements to this description. - Some additional changes were proposed at https://github.com/fonttools/fontbakery/issues/3843

fontbakery.profiles.universal.is_up_to_date(installed_str, latest_str)[source][source]