TypeTogether / Playwrite

Sensei primary repository.
SIL Open Font License 1.1
104 stars 4 forks source link

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

Closed vv-monsalve closed 1 year ago

vv-monsalve commented 1 year ago

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 (https://github.com/RedHatBrand/Overpass/issues/33). > >If the font includes tall/deep writing systems such as Arabic or Devanagari, the winAscent and winDescent can be greater than the yMax and abs(yMin) to accommodate vowel marks. > >When the win Metrics are significantly greater than the upm, the linespacing can appear too loose. To counteract this, enabling the OS/2 fsSelection bit 7 (Use_Typo_Metrics), will force Windows to use the OS/2 typo values instead. This means the font developer can control the linespacing with the typo values, whilst avoiding clipping by setting the win values to values greater than the yMax and abs(yMin). > * πŸ”₯ **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] https://github.com/googlefonts/fontbakery/issues/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 https://github.com/googlefonts/fontbakery/issues/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 (https://github.com/RedHatBrand/Overpass/issues/33). > >If the font includes tall/deep writing systems such as Arabic or Devanagari, the winAscent and winDescent can be greater than the yMax and abs(yMin) to accommodate vowel marks. > >When the win Metrics are significantly greater than the upm, the linespacing can appear too loose. To counteract this, enabling the OS/2 fsSelection bit 7 (Use_Typo_Metrics), will force Windows to use the OS/2 typo values instead. This means the font developer can control the linespacing with the typo values, whilst avoiding clipping by setting the win values to values greater than the yMax and abs(yMin). > * πŸ”₯ **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] https://github.com/googlefonts/fontbakery/issues/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 https://github.com/googlefonts/fontbakery/issues/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 (https://github.com/RedHatBrand/Overpass/issues/33). > >If the font includes tall/deep writing systems such as Arabic or Devanagari, the winAscent and winDescent can be greater than the yMax and abs(yMin) to accommodate vowel marks. > >When the win Metrics are significantly greater than the upm, the linespacing can appear too loose. To counteract this, enabling the OS/2 fsSelection bit 7 (Use_Typo_Metrics), will force Windows to use the OS/2 typo values instead. This means the font developer can control the linespacing with the typo values, whilst avoiding clipping by setting the win values to values greater than the yMax and abs(yMin). > * πŸ”₯ **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 (https://github.com/RedHatBrand/Overpass/issues/33). > >If the font includes tall/deep writing systems such as Arabic or Devanagari, the winAscent and winDescent can be greater than the yMax and abs(yMin) to accommodate vowel marks. > >When the win Metrics are significantly greater than the upm, the linespacing can appear too loose. To counteract this, enabling the OS/2 fsSelection bit 7 (Use_Typo_Metrics), will force Windows to use the OS/2 typo values instead. This means the font developer can control the linespacing with the typo values, whilst avoiding clipping by setting the win values to values greater than the yMax and abs(yMin). > * πŸ”₯ **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:

vv-monsalve commented 1 year ago

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://www.github.com/googlefonts/tools [code: bad-flags]
vv-monsalve commented 1 year ago

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 commented 1 year ago

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