Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FB main Fails and Warns reported for latest static ttf #5

Closed
vv-monsalve opened this issue Jul 27, 2023 · 3 comments
Closed

FB main Fails and Warns reported for latest static ttf #5

vv-monsalve opened this issue Jul 27, 2023 · 3 comments

Comments

@vv-monsalve
Copy link
Collaborator

vv-monsalve commented Jul 27, 2023

Following our meeting today, this is the firs FB report for the first family tested: Playpen AUS_NSW.

Please take a look at it in detail since, as we discussed, the fixes performed following this first report will impact the next families.

Since VM definition is still pending, the more critical for the time being would be the italic angle Fail (plus the name one reported in the name schema issue) and the Warns. E.g the unreachable glyphs and GDEF class

Fontbakery report

Fontbakery version: 0.8.13

[12] PlaypenAUS_NSW-ExtraLight.otf
🔥 FAIL: Check the OS/2 usWeightClass is appropriate for the font's best SubFamily name. (com.google.fonts/check/usweightclass)

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.

  • 🔥 FAIL Best SubFamily name is 'ExtraLight'. Expected OS/2 usWeightClass is 275, got 200. [code: bad-value]
🔥 FAIL: Version format is correct in 'name' table? (com.google.fonts/check/name/version_format)
  • 🔥 FAIL The NameID.VERSION_STRING (nameID=5) value must follow the pattern "Version X.Y" with X.Y greater than or equal to 1.000. Current version string is: "Version 0.200" [code: bad-version-strings]
🔥 FAIL: Check family name for GF Guide compliance. (com.google.fonts/check/name/family_name_compliance)

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

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

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

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

  • 🔥 FAIL "Playpen AUS_NSW" contains the following characters which are not allowed: "_". [code: forbidden-characters]
🔥 FAIL: 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 (RedHatOfficial/Overpass#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).

  • 🔥 FAIL OS/2.usWinAscent value should be equal or greater than 1195, but got 800 instead [code: ascent]
  • 🔥 FAIL OS/2.usWinDescent value should be equal or greater than 501, but got 400 instead. [code: descent]
🔥 FAIL: Checking post.italicAngle value. (derived from com.google.fonts/check/italic_angle) (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

  • 🔥 FAIL Font is not italic, so post.italicAngle should be equal to zero. [code: non-zero-upright]
WARN: Combined length of family and style must not exceed 27 characters. (com.google.fonts/check/name/family_and_style_max_length)

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] fonttools/fontbakery#2179

  • WARN The combined length of family and style exceeds 27 chars in the following 'WINDOWS' entries:
    FONT_FAMILY_NAME = 'Playpen AUS_NSW ExtraLight' / SUBFAMILY_NAME = 'Regular'

Please take a look at the conversation at fonttools/fontbakery#2179 in order to understand the reasoning behind these name table records max-length criteria. [code: too-long]

WARN: Ensure fonts have ScriptLangTags declared on the 'meta' table. (com.google.fonts/check/meta/script_lang_tags)

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

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

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

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

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

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

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

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

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

  • WARN This font file does not have a 'meta' table. [code: lacks-meta-table]
WARN: 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.

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

  • WARN The following glyphs could not be reached by codepoint or substitution rules:

    • A.cur_locl

    • A.dec_locl

    • F.cur_locl

    • G.cur_locl

    • G_locl

    • IJacute

    • I_locl

    • M_locl

    • Q.cur_locl

    • Q.cur_locl.ini

    • 53 more.

Use -F or --full-lists to disable shortening of long lists.
[code: unreachable-glyphs]

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

  • WARN The following spacing glyphs may be in the GDEF mark glyph class by mistake:
    periodcentered (U+00B7) and tildeshortcomb (unencoded) [code: spacing-mark-glyphs]
WARN: 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.

  • WARN The following non-mark characters should not be in the GDEF mark glyph class:
    U+00B7 [code: non-mark-chars]
WARN: Do any segments have colinear vectors? (com.google.fonts/check/outline_colinear_vectors)

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

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

  • WARN The following glyphs have colinear vectors:

    • Aogonek (U+0104): L<<582.0,6.0>--<582.0,11.0>> -> L<<582.0,11.0>--<512.0,791.0>> [code: found-colinear-vectors]
WARN: Do outlines contain any jaggy segments? (com.google.fonts/check/outline_jaggy_segments)

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

  • WARN The following glyphs have jaggy segments:

    • a (U+0061): B<<132.0,-14.0>-<197.0,-14.0>-<266.0,44.0>-<337.0,173.0>>/B<<337.0,173.0>-<329.0,143.0>-<320.0,114.0>-<312.0,84.0>> = 13.896423806079907

    • aacute (U+00E1): B<<132.0,-14.0>-<197.0,-14.0>-<266.0,44.0>-<337.0,173.0>>/B<<337.0,173.0>-<329.0,143.0>-<320.0,114.0>-<312.0,84.0>> = 13.896423806079907

    • abreve (U+0103): B<<132.0,-14.0>-<197.0,-14.0>-<266.0,44.0>-<337.0,173.0>>/B<<337.0,173.0>-<329.0,143.0>-<320.0,114.0>-<312.0,84.0>> = 13.896423806079907

    • acircumflex (U+00E2): B<<132.0,-14.0>-<197.0,-14.0>-<266.0,44.0>-<337.0,173.0>>/B<<337.0,173.0>-<329.0,143.0>-<320.0,114.0>-<312.0,84.0>> = 13.896423806079907

    • adieresis (U+00E4): B<<132.0,-14.0>-<197.0,-14.0>-<266.0,44.0>-<337.0,173.0>>/B<<337.0,173.0>-<329.0,143.0>-<320.0,114.0>-<312.0,84.0>> = 13.896423806079907

    • agrave (U+00E0): B<<132.0,-14.0>-<197.0,-14.0>-<266.0,44.0>-<337.0,173.0>>/B<<337.0,173.0>-<329.0,143.0>-<320.0,114.0>-<312.0,84.0>> = 13.896423806079907

    • amacron (U+0101): B<<132.0,-14.0>-<197.0,-14.0>-<266.0,44.0>-<337.0,173.0>>/B<<337.0,173.0>-<329.0,143.0>-<320.0,114.0>-<312.0,84.0>> = 13.896423806079907

    • aogonek (U+0105): B<<132.0,-14.0>-<197.0,-14.0>-<266.0,44.0>-<337.0,173.0>>/B<<337.0,173.0>-<329.0,143.0>-<320.0,114.0>-<312.0,84.0>> = 13.896423806079907

    • aring (U+00E5): B<<132.0,-14.0>-<197.0,-14.0>-<266.0,44.0>-<337.0,173.0>>/B<<337.0,173.0>-<329.0,143.0>-<320.0,114.0>-<312.0,84.0>> = 13.896423806079907

    • atilde (U+00E3): B<<132.0,-14.0>-<197.0,-14.0>-<266.0,44.0>-<337.0,173.0>>/B<<337.0,173.0>-<329.0,143.0>-<320.0,114.0>-<312.0,84.0>> = 13.896423806079907

    • 72 more.

Use -F or --full-lists to disable shortening of long lists. [code: found-jaggy-segments]


[11] PlaypenAUS_NSW-Light.otf
🔥 FAIL: Version format is correct in 'name' table? (com.google.fonts/check/name/version_format)
  • 🔥 FAIL The NameID.VERSION_STRING (nameID=5) value must follow the pattern "Version X.Y" with X.Y greater than or equal to 1.000. Current version string is: "Version 0.200" [code: bad-version-strings]
🔥 FAIL: Check family name for GF Guide compliance. (com.google.fonts/check/name/family_name_compliance)

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

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

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

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

  • 🔥 FAIL "Playpen AUS_NSW" contains the following characters which are not allowed: "_". [code: forbidden-characters]
🔥 FAIL: 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 (RedHatOfficial/Overpass#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).

  • 🔥 FAIL OS/2.usWinAscent value should be equal or greater than 1195, but got 800 instead [code: ascent]
  • 🔥 FAIL OS/2.usWinDescent value should be equal or greater than 501, but got 400 instead. [code: descent]
🔥 FAIL: Checking post.italicAngle value. (derived from com.google.fonts/check/italic_angle) (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

  • 🔥 FAIL Font is not italic, so post.italicAngle should be equal to zero. [code: non-zero-upright]
WARN: Combined length of family and style must not exceed 27 characters. (com.google.fonts/check/name/family_and_style_max_length)

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] fonttools/fontbakery#2179

  • WARN The combined length of family and style exceeds 27 chars in the following 'WINDOWS' entries:
    FONT_FAMILY_NAME = 'Playpen AUS_NSW Light' / SUBFAMILY_NAME = 'Regular'

Please take a look at the conversation at fonttools/fontbakery#2179 in order to understand the reasoning behind these name table records max-length criteria. [code: too-long]

WARN: Ensure fonts have ScriptLangTags declared on the 'meta' table. (com.google.fonts/check/meta/script_lang_tags)

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

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

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

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

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

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

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

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

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

  • WARN This font file does not have a 'meta' table. [code: lacks-meta-table]
WARN: 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.

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

  • WARN The following glyphs could not be reached by codepoint or substitution rules:

    • A.cur_locl

    • A.dec_locl

    • F.cur_locl

    • G.cur_locl

    • G_locl

    • IJacute

    • I_locl

    • M_locl

    • Q.cur_locl

    • Q.cur_locl.ini

    • 53 more.

Use -F or --full-lists to disable shortening of long lists.
[code: unreachable-glyphs]

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

  • WARN The following spacing glyphs may be in the GDEF mark glyph class by mistake:
    periodcentered (U+00B7) and tildeshortcomb (unencoded) [code: spacing-mark-glyphs]
WARN: 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.

  • WARN The following non-mark characters should not be in the GDEF mark glyph class:
    U+00B7 [code: non-mark-chars]
WARN: Are any segments inordinately short? (com.google.fonts/check/outline_short_segments)

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

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

  • WARN The following glyphs have segments which seem very short:

    • dollar (U+0024) contains a short segment B<<256.0,-14.0>-<262.0,-15.0>-<268.0,-15.0>-<274.0,-15.0>>

    • dollar (U+0024) contains a short segment B<<442.0,811.0>-<436.0,812.0>-<430.0,812.0>-<424.0,812.0>>

    • five (U+0035) contains a short segment B<<673.0,782.0>-<674.0,792.0>-<669.0,798.0>-<661.0,798.0>>

    • at (U+0040) contains a short segment B<<419.0,146.0>-<418.0,141.0>-<417.0,138.0>-<415.0,130.0>>

    • at (U+0040) contains a short segment B<<498.0,-56.0>-<494.0,-45.0>-<486.0,-40.0>-<476.0,-43.0>>

    • at (U+0040) contains a short segment B<<490.0,371.0>-<478.0,371.0>-<471.0,367.0>-<467.0,360.0>>

    • Ccedilla (U+00C7) contains a short segment B<<353.0,-15.0>-<357.0,-16.0>-<361.0,-16.0>-<365.0,-16.0>>

    • Ccedilla (U+00C7) contains a short segment B<<268.0,-77.0>-<263.0,-85.0>-<262.0,-91.0>-<266.0,-98.0>>

    • Ccedilla (U+00C7) contains a short segment B<<266.0,-98.0>-<269.0,-104.0>-<273.0,-107.0>-<283.0,-106.0>>

    • germandbls (U+00DF) contains a short segment B<<182.0,52.0>-<172.0,56.0>-<165.0,52.0>-<158.0,40.0>>

    • 31 more.

Use -F or --full-lists to disable shortening of long lists. [code: found-short-segments]

WARN: Do outlines contain any jaggy segments? (com.google.fonts/check/outline_jaggy_segments)

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

  • WARN The following glyphs have jaggy segments:

    • eng (U+014B): B<<365.0,415.0>-<298.0,415.0>-<217.0,360.0>-<146.0,232.0>>/L<<146.0,232.0>--<191.0,387.0>> = 12.827378086838843

    • h (U+0068): B<<370.0,415.0>-<303.0,415.0>-<222.0,360.0>-<152.0,232.0>>/L<<152.0,232.0>--<312.0,788.0>> = 12.618926826659237

    • hbar (U+0127): B<<370.0,415.0>-<303.0,415.0>-<222.0,360.0>-<152.0,232.0>>/L<<152.0,232.0>--<250.0,574.0>> = 12.683506752122385

    • hcircumflex (U+0125): B<<370.0,415.0>-<303.0,415.0>-<222.0,360.0>-<152.0,232.0>>/L<<152.0,232.0>--<312.0,788.0>> = 12.618926826659237

    • m (U+006D): B<<357.0,415.0>-<291.0,415.0>-<216.0,358.0>-<148.0,237.0>>/L<<148.0,237.0>--<191.0,387.0>> = 13.339434660755245

    • m (U+006D): B<<622.0,415.0>-<557.0,415.0>-<482.0,359.0>-<414.0,238.0>>/L<<414.0,238.0>--<423.0,268.0>> = 12.636022740284552

    • n (U+006E): B<<365.0,415.0>-<298.0,415.0>-<217.0,360.0>-<146.0,232.0>>/L<<146.0,232.0>--<191.0,387.0>> = 12.827378086838843

    • nacute (U+0144): B<<365.0,415.0>-<298.0,415.0>-<217.0,360.0>-<146.0,232.0>>/L<<146.0,232.0>--<191.0,387.0>> = 12.827378086838843

    • ncaron (U+0148): B<<365.0,415.0>-<298.0,415.0>-<217.0,360.0>-<146.0,232.0>>/L<<146.0,232.0>--<191.0,387.0>> = 12.827378086838843

    • ntilde (U+00F1): B<<365.0,415.0>-<298.0,415.0>-<217.0,360.0>-<146.0,232.0>>/L<<146.0,232.0>--<191.0,387.0>> = 12.827378086838843

    • 37 more.

Use -F or --full-lists to disable shortening of long lists. [code: found-jaggy-segments]


[10] PlaypenAUS_NSW-Regular.otf
🔥 FAIL: Version format is correct in 'name' table? (com.google.fonts/check/name/version_format)
  • 🔥 FAIL The NameID.VERSION_STRING (nameID=5) value must follow the pattern "Version X.Y" with X.Y greater than or equal to 1.000. Current version string is: "Version 0.200" [code: bad-version-strings]
🔥 FAIL: Check family name for GF Guide compliance. (com.google.fonts/check/name/family_name_compliance)

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

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

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

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

  • 🔥 FAIL "Playpen AUS_NSW" contains the following characters which are not allowed: "_". [code: forbidden-characters]
🔥 FAIL: 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 (RedHatOfficial/Overpass#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).

  • 🔥 FAIL OS/2.usWinAscent value should be equal or greater than 1195, but got 800 instead [code: ascent]
  • 🔥 FAIL OS/2.usWinDescent value should be equal or greater than 501, but got 400 instead. [code: descent]
🔥 FAIL: Checking post.italicAngle value. (derived from com.google.fonts/check/italic_angle) (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

  • 🔥 FAIL Font is not italic, so post.italicAngle should be equal to zero. [code: non-zero-upright]
WARN: Ensure fonts have ScriptLangTags declared on the 'meta' table. (com.google.fonts/check/meta/script_lang_tags)

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

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

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

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

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

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

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

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

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

  • WARN This font file does not have a 'meta' table. [code: lacks-meta-table]
WARN: 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.

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

  • WARN The following glyphs could not be reached by codepoint or substitution rules:

    • A.cur_locl

    • A.dec_locl

    • F.cur_locl

    • G.cur_locl

    • G_locl

    • IJacute

    • I_locl

    • M_locl

    • Q.cur_locl

    • Q.cur_locl.ini

    • 53 more.

Use -F or --full-lists to disable shortening of long lists.
[code: unreachable-glyphs]

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

  • WARN The following spacing glyphs may be in the GDEF mark glyph class by mistake:
    periodcentered (U+00B7) and tildeshortcomb (unencoded) [code: spacing-mark-glyphs]
WARN: 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.

  • WARN The following non-mark characters should not be in the GDEF mark glyph class:
    U+00B7 [code: non-mark-chars]
WARN: Are any segments inordinately short? (com.google.fonts/check/outline_short_segments)

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

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

  • WARN The following glyphs have segments which seem very short:

    • dollar (U+0024) contains a short segment B<<263.0,-15.0>-<267.0,-15.0>-<270.0,-15.0>-<274.0,-15.0>>

    • dollar (U+0024) contains a short segment B<<438.0,812.0>-<435.0,812.0>-<433.0,812.0>-<430.0,812.0>>

    • at (U+0040) contains a short segment B<<410.0,130.0>-<411.0,134.0>-<413.0,138.0>-<414.0,140.0>>

    • d (U+0064) contains a short segment B<<312.0,128.0>-<311.0,123.0>-<310.0,118.0>-<309.0,113.0>>

    • m (U+006D) contains a short segment L<<358.0,29.0>--<359.0,28.0>>

    • Ccedilla (U+00C7) contains a short segment B<<359.0,-15.0>-<363.0,-15.0>-<366.0,-15.0>-<370.0,-15.0>>

    • Ccedilla (U+00C7) contains a short segment B<<263.0,-78.0>-<258.0,-85.0>-<256.0,-92.0>-<261.0,-99.0>>

    • Ccedilla (U+00C7) contains a short segment B<<261.0,-99.0>-<265.0,-106.0>-<268.0,-109.0>-<280.0,-108.0>>

    • ae (U+00E6) contains a short segment B<<363.0,143.0>-<363.0,146.0>-<363.0,148.0>-<364.0,151.0>>

    • Aogonek (U+0104) contains a short segment B<<525.0,18.0>-<525.0,11.0>-<526.0,6.0>-<528.0,2.0>>

    • 33 more.

Use -F or --full-lists to disable shortening of long lists. [code: found-short-segments]

WARN: Do outlines contain any jaggy segments? (com.google.fonts/check/outline_jaggy_segments)

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

  • WARN The following glyphs have jaggy segments:

    • at (U+0040): B<<410.0,130.0>-<411.0,134.0>-<413.0,138.0>-<414.0,140.0>>/B<<414.0,140.0>-<406.0,104.0>-<398.0,44.0>-<459.0,44.0>> = 14.036243467926457

    • m (U+006D): B<<621.0,415.0>-<554.0,415.0>-<485.0,360.0>-<425.0,258.0>>/L<<425.0,258.0>--<426.0,261.0>> = 12.030596096537815

    • ordfeminine (U+00AA): B<<357.0,581.0>-<358.0,586.0>-<360.0,593.0>-<362.0,597.0>>/B<<362.0,597.0>-<351.0,561.0>-<336.0,491.0>-<405.0,491.0>> = 9.574227885091826 [code: found-jaggy-segments]


[11] PlaypenAUS_NSW-Thin.otf
🔥 FAIL: Check the OS/2 usWeightClass is appropriate for the font's best SubFamily name. (com.google.fonts/check/usweightclass)

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.

  • 🔥 FAIL Best SubFamily name is 'Thin'. Expected OS/2 usWeightClass is 250, got 100. [code: bad-value]
🔥 FAIL: Version format is correct in 'name' table? (com.google.fonts/check/name/version_format)
  • 🔥 FAIL The NameID.VERSION_STRING (nameID=5) value must follow the pattern "Version X.Y" with X.Y greater than or equal to 1.000. Current version string is: "Version 0.200" [code: bad-version-strings]
🔥 FAIL: Check family name for GF Guide compliance. (com.google.fonts/check/name/family_name_compliance)

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

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

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

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

  • 🔥 FAIL "Playpen AUS_NSW" contains the following characters which are not allowed: "_". [code: forbidden-characters]
🔥 FAIL: 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 (RedHatOfficial/Overpass#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).

  • 🔥 FAIL OS/2.usWinAscent value should be equal or greater than 1195, but got 800 instead [code: ascent]
  • 🔥 FAIL OS/2.usWinDescent value should be equal or greater than 501, but got 400 instead. [code: descent]
🔥 FAIL: Checking post.italicAngle value. (derived from com.google.fonts/check/italic_angle) (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

  • 🔥 FAIL Font is not italic, so post.italicAngle should be equal to zero. [code: non-zero-upright]
WARN: Ensure fonts have ScriptLangTags declared on the 'meta' table. (com.google.fonts/check/meta/script_lang_tags)

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

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

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

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

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

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

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

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

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

  • WARN This font file does not have a 'meta' table. [code: lacks-meta-table]
WARN: 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.

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

  • WARN The following glyphs could not be reached by codepoint or substitution rules:

    • A.cur_locl

    • A.dec_locl

    • F.cur_locl

    • G.cur_locl

    • G_locl

    • IJacute

    • I_locl

    • M_locl

    • Q.cur_locl

    • Q.cur_locl.ini

    • 53 more.

Use -F or --full-lists to disable shortening of long lists.
[code: unreachable-glyphs]

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

  • WARN The following spacing glyphs may be in the GDEF mark glyph class by mistake:
    periodcentered (U+00B7) and tildeshortcomb (unencoded) [code: spacing-mark-glyphs]
WARN: 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.

  • WARN The following non-mark characters should not be in the GDEF mark glyph class:
    U+00B7 [code: non-mark-chars]
WARN: Do any segments have colinear vectors? (com.google.fonts/check/outline_colinear_vectors)

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

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

  • WARN The following glyphs have colinear vectors:

    • ampersand (U+0026): L<<270.0,370.0>--<273.0,366.0>> -> L<<273.0,366.0>--<458.0,116.0>>

    • uni0162 (U+0162): L<<462.0,770.0>--<240.0,1.0>> -> L<<240.0,1.0>--<239.0,-4.0>> [code: found-colinear-vectors]

WARN: Do outlines contain any jaggy segments? (com.google.fonts/check/outline_jaggy_segments)

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

  • WARN The following glyphs have jaggy segments:

    • a (U+0061): B<<136.0,-14.0>-<205.0,-14.0>-<277.0,49.0>-<352.0,195.0>>/B<<352.0,195.0>-<341.0,153.0>-<328.0,111.0>-<317.0,69.0>> = 12.513110474627924

    • aacute (U+00E1): B<<136.0,-14.0>-<205.0,-14.0>-<277.0,49.0>-<352.0,195.0>>/B<<352.0,195.0>-<341.0,153.0>-<328.0,111.0>-<317.0,69.0>> = 12.513110474627924

    • abreve (U+0103): B<<136.0,-14.0>-<205.0,-14.0>-<277.0,49.0>-<352.0,195.0>>/B<<352.0,195.0>-<341.0,153.0>-<328.0,111.0>-<317.0,69.0>> = 12.513110474627924

    • acircumflex (U+00E2): B<<136.0,-14.0>-<205.0,-14.0>-<277.0,49.0>-<352.0,195.0>>/B<<352.0,195.0>-<341.0,153.0>-<328.0,111.0>-<317.0,69.0>> = 12.513110474627924

    • adieresis (U+00E4): B<<136.0,-14.0>-<205.0,-14.0>-<277.0,49.0>-<352.0,195.0>>/B<<352.0,195.0>-<341.0,153.0>-<328.0,111.0>-<317.0,69.0>> = 12.513110474627924

    • agrave (U+00E0): B<<136.0,-14.0>-<205.0,-14.0>-<277.0,49.0>-<352.0,195.0>>/B<<352.0,195.0>-<341.0,153.0>-<328.0,111.0>-<317.0,69.0>> = 12.513110474627924

    • amacron (U+0101): B<<136.0,-14.0>-<205.0,-14.0>-<277.0,49.0>-<352.0,195.0>>/B<<352.0,195.0>-<341.0,153.0>-<328.0,111.0>-<317.0,69.0>> = 12.513110474627924

    • aogonek (U+0105): B<<136.0,-14.0>-<205.0,-14.0>-<277.0,49.0>-<352.0,195.0>>/B<<352.0,195.0>-<341.0,153.0>-<328.0,111.0>-<317.0,69.0>> = 12.513110474627924

    • aring (U+00E5): B<<136.0,-14.0>-<205.0,-14.0>-<277.0,49.0>-<352.0,195.0>>/B<<352.0,195.0>-<341.0,153.0>-<328.0,111.0>-<317.0,69.0>> = 12.513110474627924

    • at (U+0040): B<<285.0,42.0>-<333.0,42.0>-<384.0,80.0>-<436.0,178.0>>/B<<436.0,178.0>-<430.0,155.0>-<425.0,137.0>-<417.0,108.0>> = 13.330095039258493

    • 74 more.

Use -F or --full-lists to disable shortening of long lists. [code: found-jaggy-segments]


Summary

💔 ERROR 🔥 FAIL ⚠ WARN 💤 SKIP ℹ INFO 🍞 PASS 🔎 DEBUG
0 18 26 535 25 329 0
0% 2% 3% 57% 3% 35% 0%

Note: The following loglevels were omitted in this report:

  • SKIP
  • INFO
  • PASS
  • DEBUG
@vv-monsalve vv-monsalve changed the title FB report for for current .otf fonts FB main Fails reported for latest static ttf Aug 28, 2023
@vv-monsalve
Copy link
Collaborator Author

vv-monsalve commented Aug 28, 2023

The following are the some Fails reported for the static fonts (models) pulled from lang-build branch at commit bf1024c.
I created separate issues for the ones that require more attention at the source file level.

Please check and ensure to solve them for all the fonts/models.

🔥 FAIL: PPEM must be an integer on hinted fonts. (com.google.fonts/check/integer_ppem_if_hinted)

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;

  • 🔥 FAIL This is a hinted font, so it must have bit 3 set on the flags of the head table, so that PPEM values will be rounded into an integer value.

This can be accomplished by using the 'gftools fix-hinting' command.

create virtualenv

python3 -m venv venv

activate virtualenv

source venv/bin/activate

install gftools

pip install git+https://github.com/googlefonts/tools [code: bad-flags]

@vv-monsalve
Copy link
Collaborator Author

post.italicAngle

🔥 FAIL: Checking post.italicAngle value. (derived from com.google.fonts/check/italic_angle) (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

  • 🔥 FAIL Font is not italic, so post.italicAngle should be equal to zero. [code: non-zero-upright]

@vv-monsalve vv-monsalve changed the title FB main Fails reported for latest static ttf FB main Fails and Warns reported for latest static ttf Aug 28, 2023
@vv-monsalve
Copy link
Collaborator Author

The above fails are still reported for the families at commit 1b4d055. They have been followed up in the separate issues #19 and #20. So closing this issue here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant