Checking...

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

com.google.fonts/check/varfont/regular_wght_coord

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • FAIL :

      "Regular" instance not present.

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.

com.adobe.fonts/check/varfont/valid_default_instance_nameids

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • FAIL :

      'wght=100' instance has the same coordinates as the default instance; its subfamily name should be 'Flipbook VAR'

    • FAIL :

      'wght=100' instance has the same coordinates as the default instance; its postscript name should be 'FlipbookV1-FlipbookVAR', instead of 'FlipbookV1FlipbookVAR-wght=100'.

Checking OS/2 Metrics match hhea Metrics.

com.google.fonts/check/os2_metrics_match_hhea

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • FAIL :

      OS/2 sTypoAscender (800) and hhea ascent (1000) must be equal.

Does the font have a DSIG table?

com.google.fonts/check/dsig

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

  • FlipbookV1-FlipbookVARVF.ttf
    • WARN :

      This font has a digital signature (DSIG table) which is only required - even if only a placeholder - on old programs like MS Office 2013 in order to work properly. The current recommendation is to completely remove the DSIG table.

Ensure 'ital' STAT axis is boolean value

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • WARN :

      STAT table 'ital' axis is not linked to Italic.

Checking Vertical Metric Linegaps.

com.google.fonts/check/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.

  • FlipbookV1-FlipbookVARVF.ttf
    • WARN :

      hhea lineGap is not equal to 0.

List all superfamily filepaths

com.google.fonts/check/superfamily/list

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • INFO :

      .

Font contains all required tables?

com.google.fonts/check/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.
  • FlipbookV1-FlipbookVARVF.ttf
    • INFO :

      This font contains the following optional tables:

      - loca
      
      - GPOS
      
    • PASS :

      Font contains all required tables.

Ensure that the font can be rasterized by FreeType.

com.adobe.fonts/check/freetype_rasterizer

Malformed fonts can cause FreeType to crash.

  • This check cannot be run in the web environment. This is because the Freetype library cannot be compiled for WASM. The web version of fontbakery is not a full replacement for the Python version, and we recommend that you install fontbakery and check your fonts locally to ensure that all checks are run.

Checking with ots-sanitize.

com.google.fonts/check/ots

The OpenType Sanitizer (OTS) is a tool that checks that the font is structually well-formed and passes various sanity checks. It is used by many web browsers to check web fonts before using them; fonts which fail such checks are blocked by browsers.

This check runs OTS on the font and reports any errors or warnings that it finds.

  • This check cannot be run in the web environment. This is because the OpenType Sanitizer library cannot be compiled for WASM. The web version of fontbakery is not a full replacement for the Python version, and we recommend that you install fontbakery and check your fonts locally to ensure that all checks are run.

Check tabular widths don't have kerning.

com.google.fonts/check/tabular_kerning

Tabular glyphs should not have kerning, as they are meant to be used in tables.

This check looks for kerning in:

  • all glyphs in a font in combination with tabular numerals;
  • tabular symbols in combination with tabular numerals.

"Tabular symbols" is defined as:

  • for fonts with a "tnum" feature, all "tnum" substitution target glyphs;
  • for fonts without a "tnum" feature, all glyphs that have the same width as the tabular numerals, but limited to numbers, math and currency symbols.

This check may produce false positives for fonts with no "tnum" feature and with equal-width numerals (and other same-width symbols) that are not intended to be used as tabular numerals.

  • FlipbookV1-FlipbookVARVF.ttf
    • ERROR :

      Failed with KeyError: None

        File "/lib/python3.11/site-packages/fontbakery/checkrunner.py", line 213, in _run_check
          subresults = list(subresults)
                       ^^^^^^^^^^^^^^^^
        File "/lib/python3.11/site-packages/fontbakery/checks/universal/__init__.py", line 2492, in com_google_fonts_check_tabular_kerning
          glyph_widths = [
                         ^
        File "/lib/python3.11/site-packages/fontbakery/checks/universal/__init__.py", line 2493, in <listcomp>
          glyph_width(ttFont, glyph_name_for_character(ttFont, str(i)))
        File "/lib/python3.11/site-packages/fontbakery/checks/universal/__init__.py", line 2391, in glyph_width
          return ttFont["hmtx"].metrics[glyph_name][0]
                 ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^
      
      

Fonts have consistent underline thickness?

com.google.fonts/check/family/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.

  • PASS :

    Fonts have consistent underline thickness.

Fonts have consistent PANOSE family type?

com.google.fonts/check/family/panose_familytype

The PANOSE value in the OS/2 table is a way of classifying a font based on its visual appearance and characteristics.

The first field in the PANOSE classification is the family type: 2 means Latin Text, 3 means Latin Script, 4 means Latin Decorative, 5 means Latin Symbol. This check ensures that within a family, all fonts have the same family type.

  • PASS :

    Fonts have consistent PANOSE family type.

Make sure all font files have the same version value.

com.google.fonts/check/family/equal_font_versions

Within a family released at the same time, all members of the family should have the same version number in the head table.

  • PASS :

    All font files have the same version.

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

com.adobe.fonts/check/family/bold_italic_unique_for_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.

  • PASS :

    The OS/2.fsSelection bold & italic settings were unique within each compatible family group.

Verify that each group of fonts with the same nameID 1 has maximum of 4 fonts.

com.adobe.fonts/check/family/max_4_fonts_per_family_name

Per the OpenType spec:

'The Font Family name [...] should be shared among at most four fonts that differ only in weight or style [...]'

  • PASS :

    There were no more than 4 fonts per family name.

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)

com.adobe.fonts/check/family/consistent_family_name

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.

  • PASS :

    Font family names are consistent across the family.

Name table ID 6 (PostScript name) must be consistent across platforms.

com.adobe.fonts/check/name/postscript_name_consistency

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      Entries in the "name" table for ID 6 (PostScript name) are consistent.

Check name table for empty records.

com.adobe.fonts/check/name/empty_records

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

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      No empty name table records found.

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

com.google.fonts/check/name/no_copyright_on_description

The name table in a font file contains strings about the font; there are entries for a copyright field and a description. If the copyright entry is being used correctly, then there should not be any copyright information in the description entry.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      Description strings in the name table do not contain any copyright string.

Does full font name begin with the font family name?

com.google.fonts/check/name/match_familyname_fullfont

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

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      Full font name begins with the font family name.

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

com.google.fonts/check/varfont/wght_valid_range

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      OK

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

com.google.fonts/check/varfont/stat_axis_record_for_each_axis

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

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      STAT table has all necessary Axis Records.

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

com.google.fonts/check/loca/maxp_num_glyphs

The 'maxp' table contains various statistics about the font, including the number of glyphs in the font. The 'loca' table contains the offsets to the locations of the glyphs in the font. The number of offsets in the 'loca' table should match the number of glyphs in the 'maxp' table. A failure here indicates a problem with the font compiler.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      'loca' table matches numGlyphs in 'maxp' table.

Checking font version fields (head and name table).

com.google.fonts/check/font_version

The OpenType specification provides for two fields which contain the version number of the font: fontRevision in the head table, and nameID 5 in the name table. If these fields do not match, different applications will report different version numbers for the font.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      All font version fields match.

Font has correct post table version?

com.google.fonts/check/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.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      Font has an acceptable post format 2.0 table version.

Checking correctness of monospaced metadata.

com.google.fonts/check/monospace

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:

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

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      Font is not monospaced and all related metadata look good.

Check if OS/2 xAvgCharWidth is correct.

com.google.fonts/check/xavgcharwidth

The OS/2.xAvgCharWidth field is used to calculate the width of a string of characters. It is the average width of all non-zero width glyphs in the font.

This check ensures that the value is correct. A failure here may indicate a bug in the font compiler, rather than something that the designer can do anything about.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      OS/2 xAvgCharWidth value is correct.

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

com.adobe.fonts/check/fsselection_matches_macstyle

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

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      The OS/2.fsSelection and head.macStyle bold and italic settings match.

Checking unitsPerEm value is reasonable.

com.google.fonts/check/unitsperem

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      The unitsPerEm value (1000) on the 'head' table is reasonable.

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

com.google.fonts/check/gpos_kerning_info

Well-designed fonts use kerning to improve the spacing between specific pairs of glyphs. This check ensures that the font has kerning information in the GPOS table. It can be ignored if the design or writing system does not require kerning.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      GPOS table check for kerning information passed.

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

com.google.fonts/check/kern_table

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      Font does not declare an optional "kern" table.

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

com.google.fonts/check/glyf_unused_data

This check validates the structural integrity of the glyf table, by checking that all glyphs referenced in the loca table are actually present in the glyf table and that there is no unused data at the end of the glyf table. A failure here indicates a problem with the font compiler.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      There is no unused data at the end of the glyf table.

Font follows the family naming recommendations?

com.google.fonts/check/family_naming_recommendations

This check ensures that the length of various family name and style name strings in the name table are within the maximum length recommended by the OpenType specification.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      Font follows the family naming recommendations.

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

com.google.fonts/check/maxadvancewidth

The 'hhea' table contains a field which specifies the maximum advance width. This value should be consistent with the maximum advance width of all glyphs specified in the 'hmtx' table.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

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

PostScript name follows OpenType specification requirements?

com.adobe.fonts/check/postscript_name

The PostScript name is used by some applications to identify the font. It should only consist of characters from the set A-Z, a-z, 0-9, and hyphen.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      PostScript name follows requirements.

Check for points out of bounds.

com.google.fonts/check/points_out_of_bounds

The glyf table specifies a bounding box for each glyph. This check ensures that all points in all glyph paths are within the bounding box. Glyphs with out-of-bounds points can cause rendering issues in some software, and should be corrected.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      All glyph paths have coordinates within bounds!

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

com.google.fonts/check/glyf_non_transformed_duplicate_components

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      Glyphs do not contain duplicate components which have the same x,y coordinates.

Check code page character ranges

com.google.fonts/check/code_pages

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      At least one code page is defined.

Does the font have any invalid feature tags?

com.google.fonts/check/layout_valid_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.

Font vendors may use private tags to identify private features. These tags must be four uppercase letters (A-Z) with no punctuation, spaces, or numbers.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      No invalid feature tags were found

Does the font have any invalid script tags?

com.google.fonts/check/layout_valid_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.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      No invalid script tags were found

Does the font have any invalid language tags?

com.google.fonts/check/layout_valid_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.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      No invalid language tags were found

Checking post.italicAngle value.

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

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      Value of post.italicAngle is 0.0 with style="Regular".

Checking head.macStyle value.

com.google.fonts/check/mac_style

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      head macStyle ITALIC bit is properly set.

    • PASS :

      head macStyle BOLD bit is properly set.

Checking OS/2 fsSelection value.

com.google.fonts/check/fsselection

The OS/2.fsSelection field is a bit field used to specify the stylistic qualities of the font - in particular, it specifies to some operating systems whether the font is italic (bit 0), bold (bit 5) or regular (bit 6).

This check verifies that the fsSelection field is set correctly for the font style. For a family of static fonts created in GlyphsApp, this is set by using the style linking checkboxes in the exports settings.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      OS/2 fsSelection REGULAR bit is properly set.

    • PASS :

      OS/2 fsSelection ITALIC bit is properly set.

    • PASS :

      OS/2 fsSelection BOLD bit is properly set.

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

com.adobe.fonts/check/varfont/valid_axis_nameid

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      All axisNameID values are valid.

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

com.adobe.fonts/check/varfont/valid_subfamily_nameid

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      All subfamilyNameID values are valid.

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

com.adobe.fonts/check/varfont/valid_postscript_nameid

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      All postScriptNameID values are valid.

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

com.adobe.fonts/check/varfont/same_size_instance_records

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      All instance records have the same size.

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

com.adobe.fonts/check/varfont/distinct_instance_records

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      All instance records are distinct.

Validate foundry-defined design-variation axis tag names.

com.adobe.fonts/check/varfont/foundry_defined_tag_name

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      Axis tag 'wght' looks good.

Check that family axis ranges are indentical

com.google.fonts/check/varfont/family_axis_ranges

Between members of a family (such as Roman & Italic), the ranges of variable axes must be identical.

  • PASS :

    Variable axes ranges are matching between font files

STAT table has Axis Value tables?

com.adobe.fonts/check/stat_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

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      STAT table has Axis Value tables.

Check hhea.caretSlopeRise and hhea.caretSlopeRun

com.google.fonts/check/caret_slope

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

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

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

Ensure VFs have 'ital' STAT axis.

com.google.fonts/check/italic_axis_in_stat

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

  • PASS :

    OK

Ensure 'ital' STAT axis is last.

com.google.fonts/check/italic_axis_last

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

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      STAT table ital axis order is good.

Check accent of Lcaron, dcaron, lcaron, tcaron

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

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      Looks good!

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

com.google.fonts/check/arabic_spacing_symbols

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      Looks good!

Ensure the font supports case swapping for all its glyphs.

com.google.fonts/check/case_mapping

Ensure that no glyph lacks its corresponding upper or lower counterpart (but only when unicode supports case-mapping).

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      Looks good!

Checking all files are in the same directory.

com.google.fonts/check/family/single_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).

  • PASS :

    All files are in the same directory.

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

com.google.fonts/check/family/vertical_metrics

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

  • PASS :

    Vertical metrics are the same across the family.

Checking OS/2 usWinAscent & usWinDescent.

com.google.fonts/check/family/win_ascent_and_descent

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      OS/2 usWinAscent & usWinDescent values look good!

Ensure no GPOS7 lookups are present.

com.google.fonts/check/gpos7

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      Font has no GPOS7 lookups

Detect any interpolation issues in the font.

com.google.fonts/check/interpolation_issues

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      No interpolation issues found

Font contains '.notdef' as its first glyph?

com.google.fonts/check/mandatory_glyphs

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      OK

Check math signs have the same width.

com.google.fonts/check/math_signs_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.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      Looks good.

Name table records must not have trailing spaces.

com.google.fonts/check/name/trailing_spaces

This check ensures that no entries in the name table end in spaces; trailing spaces, particularly in font names, can be confusing to users. In most cases this can be fixed by removing trailing spaces from the metadata fields in the font editor.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      No trailing spaces on name table entries.

Font has the proper sfntVersion value?

com.adobe.fonts/check/sfnt_version

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

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      Font has the correct sfntVersion value.

Does the font contain a soft hyphen?

com.google.fonts/check/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

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      Looks good!

Check correctness of STAT table strings

com.google.fonts/check/STAT_strings

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

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      Looks good!

Ensure component transforms do not perform scaling or rotation.

com.google.fonts/check/transformed_components

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

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      No glyphs had components with scaling or rotation

Checking with fontTools.ttx

com.google.fonts/check/ttx_roundtrip

One way of testing whether or not fonts are well-formed at the binary level is to convert them to TTX and then back to binary. Structural problems within the binary font will show up as errors during conversion. This is not necessarily something that a designer will be able to address but is evidence of a potential bug in the font compiler used to generate the binary.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      Hey! It all looks good!

Font contains unique glyph names?

com.google.fonts/check/unique_glyphnames

Duplicate glyph names prevent font installation on Mac OS X.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      Glyph names are all unique.

Check font contains no unreachable glyphs

com.google.fonts/check/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. And mathematical fonts also reference glyphs via the MATH table.

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

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      Font did not contain any unreachable glyphs

Are there unwanted tables?

com.google.fonts/check/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.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      There are no unwanted tables.

Glyph names are all valid?

com.google.fonts/check/valid_glyphnames

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

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      Glyph names are all valid.

Font has **proper** whitespace glyph names?

com.google.fonts/check/whitespace_glyphnames

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

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      Font has AGL recommended names for whitespace glyphs.

Font contains glyphs for whitespace characters?

com.google.fonts/check/whitespace_glyphs

The OpenType specification recommends that fonts should contain glyphs for the following whitespace characters:

  • U+0020 SPACE
  • U+00A0 NO-BREAK SPACE

The space character is required for text processing, and the no-break space is useful to prevent line breaks at its position. It is also recommended to have a glyph for the tab character (U+0009) and the soft hyphen (U+00AD), but these are not mandatory.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      Font contains glyphs for whitespace characters.

Whitespace glyphs have ink?

com.google.fonts/check/whitespace_ink

This check ensures that certain whitespace glyphs are empty. Certain text layout engines will assume that these glyphs are empty, and will not draw them; if they were in fact not designed to be empty, the result will be text layout that is not as expected.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      There is no whitespace glyph with ink.

Space and non-breaking space have the same width?

com.google.fonts/check/whitespace_widths

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • PASS :

      Space and non-breaking space have the same width.

CFF table FontName must match name table ID 6 (PostScript name).

com.adobe.fonts/check/name/postscript_vs_cff

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • SKIP :

      Unfulfilled Conditions: is_cff

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

com.google.fonts/check/varfont/regular_wdth_coord

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • SKIP :

      Unfulfilled Conditions: has_wdth_axis

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

com.google.fonts/check/varfont/regular_slnt_coord

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • SKIP :

      Unfulfilled Conditions: has_slnt_axis

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

com.google.fonts/check/varfont/regular_ital_coord

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • SKIP :

      Unfulfilled Conditions: has_ital_axis

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

com.google.fonts/check/varfont/regular_opsz_coord

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • SKIP :

      Unfulfilled Conditions: has_opsz_axis

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

com.google.fonts/check/varfont/slnt_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.

  • FlipbookV1-FlipbookVARVF.ttf
    • SKIP :

      Unfulfilled Conditions: has_slnt_axis

The variable font 'ital' (Italic) axis coordinates is in a valid range?

com.typenetwork/check/varfont/ital_range

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

[...] Valid numeric range: Values must be in the range 0 to 1.

  • FlipbookV1-FlipbookVARVF.ttf
    • SKIP :

      Unfulfilled Conditions: has_ital_axis

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

com.google.fonts/check/varfont/wdth_valid_range

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • SKIP :

      Unfulfilled Conditions: has_wdth_axis

Is the CFF2 subr/gsubr call depth > 10?

com.adobe.fonts/check/cff2_call_depth

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

  • FlipbookV1-FlipbookVARVF.ttf
    • SKIP :

      Unfulfilled Conditions: is_cff2

Is the CFF subr/gsubr call depth > 10?

com.adobe.fonts/check/cff_call_depth

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

  • FlipbookV1-FlipbookVARVF.ttf
    • SKIP :

      Unfulfilled Conditions: is_cff

Does the font use deprecated CFF operators or operations?

com.adobe.fonts/check/cff_deprecated_operators

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • SKIP :

      Unfulfilled Conditions: is_cff

Check glyphs in mark glyph class are non-spacing.

com.google.fonts/check/gdef_spacing_marks

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • SKIP :

      Font does not declare an optional "GDEF" table or has any GDEF glyph class definition.

Check mark characters are in GDEF mark glyph class.

com.google.fonts/check/gdef_mark_chars

Mark characters should be in the GDEF mark glyph class.

  • FlipbookV1-FlipbookVARVF.ttf
    • SKIP :

      Font does not declare an optional "GDEF" table or has any GDEF glyph class definition.

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

com.google.fonts/check/gdef_non_mark_chars

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • SKIP :

      Font does not declare an optional "GDEF" table or has any GDEF glyph class definition.

Check name table IDs 1, 2, 16, 17 to conform to Italic style.

com.google.fonts/check/name/italic_names

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • SKIP :

      Font is not Italic.

Checking OS/2 achVendID against configuration.

com.thetypefounders/check/vendor_id

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • SKIP :

      Add the vendor_id key to a fontbakery.yaml file on your font project directory to enable this check. You'll also need to use the --configuration flag when invoking fontbakery.

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

com.google.fonts/check/superfamily/vertical_metrics

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • SKIP :

      Sibling families were not detected.

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

com.google.fonts/check/arabic_high_hamza

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • SKIP :

      This check will only run on fonts that have both glyphs U+0621 and U+0675

Does the font contain chws and vchw features?

com.google.fonts/check/cjk_chws_feature

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • SKIP :

      Unfulfilled Conditions: is_cjk_font

Check if each glyph has the recommended amount of contours.

com.google.fonts/check/contour_count

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.

  • FlipbookV1-FlipbookVARVF.ttf
    • SKIP :

      Unfulfilled Conditions: not is_variable_font

Ensure indic fonts have the Indian Rupee Sign glyph.

com.google.fonts/check/rupee

Per Bureau of Indian Standards every font supporting one of the official Indian languages needs to include Unicode Character β€œβ‚Ήβ€ (U+20B9) Indian Rupee Sign.

  • FlipbookV1-FlipbookVARVF.ttf
    • SKIP :

      Unfulfilled Conditions: is_indic_font

Checking STAT table entries in static fonts.

com.google.fonts/check/STAT_in_statics

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

  • FlipbookV1-FlipbookVARVF.ttf
    • SKIP :

      Unfulfilled Conditions: not is_variable_font