sourcecodepro: v1.018 added #4010
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
RosaWagner
added
- Ready for Review
I Font Upgrade
III VF Replacement
Fontbakery reportFontbakery version: 0.8.3 [1] Family checks⚠ WARN: Make sure all font files have the same version value.
[28] SourceCodePro-Italic[wght].ttf🔥 FAIL: Substitute copyright, registered and trademark symbols in name table entries.
🔥 FAIL: Check license file has good copyright string.--- Rationale --- An OFL.txt file's first line should be the font copyright e.g: "Copyright 2019 The Montserrat Project Authors (https://github.com/julietaula/montserrat)"
🔥 FAIL: Check OFL body text is correct.--- Rationale --- Check OFL body text is correct. Often users will accidently delete parts of the body text.
🔥 FAIL: Check copyright namerecords match license file.--- Rationale --- A known licensing description must be provided in the NameID 14 (LICENSE DESCRIPTION) entries of the name table. The source of truth for this check (to determine which license is in use) is a file placed side-by-side to your font project including the licensing terms. Depending on the chosen license, one of the following string snippets is expected to be found on the NameID 13 (LICENSE DESCRIPTION) entries of the name table: - "This Font Software is licensed under the SIL Open Font License, Version 1.1. This license is available with a FAQ at: https://scripts.sil.org/OFL" - "Licensed under the Apache License, Version 2.0" - "Licensed under the Ubuntu Font Licence 1.0." Currently accepted licenses are Apache or Open Font License. For a small set of legacy families the Ubuntu Font License may be acceptable as well. When in doubt, please choose OFL for new font projects.
🔥 FAIL: Are there non-ASCII characters in ASCII-only NAME table entries?--- Rationale --- The OpenType spec requires ASCII for the POSTSCRIPT_NAME (nameID 6). For COPYRIGHT_NOTICE (nameID 0) ASCII is required because that string should be the same in CFF fonts which also have this requirement in the OpenType spec. Note: A common place where we find non-ASCII strings is on name table entries with NameID > 18, which are expressly for localising the ASCII-only IDs into Hindi / Arabic / etc.
🔥 FAIL: Checks METADATA.pb font.post_script_name matches postscript name declared on the name table.
🔥 FAIL: METADATA.pb font.full_name value matches fullname declared on the name table?
🔥 FAIL: METADATA.pb font.full_name and font.post_script_name fields have equivalent values ?
🔥 FAIL: METADATA.pb font.post_script_name field contains font name in right format?
🔥 FAIL: Copyright notices match canonical pattern in METADATA.pb--- Rationale --- The expected pattern for the copyright string adheres to the following rules: * It must say "Copyright" followed by a 4 digit year (optionally followed by a hyphen and another 4 digit year) * Then it must say "The <familyname> Project Authors" * And within parentheses, a URL for a git repository must be provided * The check is case insensitive and does not validate whether the familyname is correct, even though we'd expect it is (and we may soon update the check to validate that aspect as well!) Here is an example of a valid copyright string: "Copyright 2017 The Archivo Black Project Authors (https://github.com/Omnibus-Type/ArchivoBlack)"
🔥 FAIL: Copyright notices match canonical pattern in fonts
🔥 FAIL: Ensure component transforms do not perform scaling or rotation.--- Rationale --- Some families have glyphs which have been constructed by using transformed components e.g the 'u' being constructed from a flipped 'n'. From a designers point of view, this sounds like a win (less work). However, such approaches can lead to rasterization issues, such as having the 'u' not sitting on the baseline at certain sizes after running the font through ttfautohint. 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, this problem can be fixed by using the "Decompose Transformed Components" filter.
🔥 FAIL: Check name table: FONT_SUBFAMILY_NAME entries.
🔥 FAIL: Check name table: TYPOGRAPHIC_SUBFAMILY_NAME entries.--- Rationale --- Requirements for the TYPOGRAPHIC_SUBFAMILY_NAME entries in the 'name' table.
🔥 FAIL: Check glyphs do not have components which are themselves components.--- Rationale --- There have been bugs rendering variable fonts with nested components. Additionally, some static fonts with nested components have been reported to have rendering and printing issues. For more info, see: * https://github.com/googlefonts/fontbakery/issues/2961 * https://github.com/arrowtype/recursive/issues/412
🔥 FAIL: Name table strings must not contain the string 'Reserved Font Name'.--- Rationale --- Some designers adopt the "Reserved Font Name" clause of the OFL license. This means that the original author reserves the rights to the family name and other people can only distribute modified versions using a different family name. Google Fonts published updates to the fonts in the collection in order to fix issues and/or implement further improvements to the fonts. It is important to keep the family name so that users of the webfonts can benefit from the updates. Since it would forbid such usage scenario, all families in the GFonts collection are required to not adopt the RFN clause. This check ensures "Reserved Font Name" is not mentioned in the name table.
🔥 FAIL: Font has correct post table version?--- Rationale --- Apple recommends against using 'post' table format 3 under most circumstances, as it can create problems with some printer drivers and PDF documents. The savings in disk space usually does not justify the potential loss in functionality. Source: https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6post.html The CFF2 table does not contain glyph names, so variable OTFs should be allowed to use post table version 2. This check expects: - Version 2 for TTF or OTF CFF2 Variable fonts - Version 3 for OTF
🔥 FAIL: Name table ID 6 (PostScript name) must be consistent across platforms.--- Rationale --- 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.
⚠ WARN: License URL matches License text on name table?--- Rationale --- A known license URL must be provided in the NameID 14 (LICENSE INFO URL) entry of the name table. The source of truth for this check is the licensing text found on the NameID 13 entry (LICENSE DESCRIPTION). The string snippets used for detecting licensing terms are: - "This Font Software is licensed under the SIL Open Font License, Version 1.1. This license is available with a FAQ at: https://scripts.sil.org/OFL" - "Licensed under the Apache License, Version 2.0" - "Licensed under the Ubuntu Font Licence 1.0." Currently accepted licenses are Apache or Open Font License. For a small set of legacy families the Ubuntu Font License may be acceptable as well. When in doubt, please choose OFL for new font projects.
⚠ WARN: Copyright notice on METADATA.pb should not contain 'Reserved Font Name'.
⚠ WARN: Combined length of family and style must not exceed 27 characters.--- Rationale --- 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
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: A static fonts directory with at least two fonts must accompany variable fonts--- Rationale --- Variable font family directories kept in the google/fonts git repo may include a static/ subdir containing static fonts. These files are meant to be served for users that still lack support for variable fonts in their web browsers.
⚠ WARN: On a family update, the DESCRIPTION.en_us.html file should ideally also be updated.--- Rationale --- We want to ensure that any significant changes to the font family are properly mentioned in the DESCRIPTION file. In general, it means that the contents of the DESCRIPTION.en_us.html file will typically change if when font files are updated. Please treat this check as a reminder to do so whenever appropriate!
⚠ WARN: Ensure fonts have ScriptLangTags declared on the 'meta' table.--- Rationale --- 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: Check font contains no unreachable glyphs--- Rationale --- Glyphs are either accessible directly through Unicode codepoints or through substitution rules. Any glyphs not accessible by either of these means are redundant and serve only to increase the font's file size.
⚠ WARN: Does the font have a DSIG table?--- Rationale --- 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 dummy DSIG table by running one of the helper scripts provided at https://github.com/googlefonts/gftools Reference: https://github.com/googlefonts/fontbakery/issues/1845
⚠ WARN: Check glyphs in mark glyph class are non-spacing.--- Rationale --- 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: Check mark characters are in GDEF mark glyph class.--- Rationale --- Mark characters should be in the GDEF mark glyph class.
[27] SourceCodePro[wght].ttf🔥 FAIL: Substitute copyright, registered and trademark symbols in name table entries.
🔥 FAIL: Check license file has good copyright string.--- Rationale --- An OFL.txt file's first line should be the font copyright e.g: "Copyright 2019 The Montserrat Project Authors (https://github.com/julietaula/montserrat)"
🔥 FAIL: Check OFL body text is correct.--- Rationale --- Check OFL body text is correct. Often users will accidently delete parts of the body text.
🔥 FAIL: Check copyright namerecords match license file.--- Rationale --- A known licensing description must be provided in the NameID 14 (LICENSE DESCRIPTION) entries of the name table. The source of truth for this check (to determine which license is in use) is a file placed side-by-side to your font project including the licensing terms. Depending on the chosen license, one of the following string snippets is expected to be found on the NameID 13 (LICENSE DESCRIPTION) entries of the name table: - "This Font Software is licensed under the SIL Open Font License, Version 1.1. This license is available with a FAQ at: https://scripts.sil.org/OFL" - "Licensed under the Apache License, Version 2.0" - "Licensed under the Ubuntu Font Licence 1.0." Currently accepted licenses are Apache or Open Font License. For a small set of legacy families the Ubuntu Font License may be acceptable as well. When in doubt, please choose OFL for new font projects.
🔥 FAIL: Are there non-ASCII characters in ASCII-only NAME table entries?--- Rationale --- The OpenType spec requires ASCII for the POSTSCRIPT_NAME (nameID 6). For COPYRIGHT_NOTICE (nameID 0) ASCII is required because that string should be the same in CFF fonts which also have this requirement in the OpenType spec. Note: A common place where we find non-ASCII strings is on name table entries with NameID > 18, which are expressly for localising the ASCII-only IDs into Hindi / Arabic / etc.
🔥 FAIL: Checks METADATA.pb font.post_script_name matches postscript name declared on the name table.
🔥 FAIL: METADATA.pb font.full_name value matches fullname declared on the name table?
🔥 FAIL: METADATA.pb font.full_name and font.post_script_name fields have equivalent values ?
🔥 FAIL: METADATA.pb font.post_script_name field contains font name in right format?
🔥 FAIL: Copyright notices match canonical pattern in METADATA.pb--- Rationale --- The expected pattern for the copyright string adheres to the following rules: * It must say "Copyright" followed by a 4 digit year (optionally followed by a hyphen and another 4 digit year) * Then it must say "The <familyname> Project Authors" * And within parentheses, a URL for a git repository must be provided * The check is case insensitive and does not validate whether the familyname is correct, even though we'd expect it is (and we may soon update the check to validate that aspect as well!) Here is an example of a valid copyright string: "Copyright 2017 The Archivo Black Project Authors (https://github.com/Omnibus-Type/ArchivoBlack)"
🔥 FAIL: Copyright notices match canonical pattern in fonts
🔥 FAIL: Ensure component transforms do not perform scaling or rotation.--- Rationale --- Some families have glyphs which have been constructed by using transformed components e.g the 'u' being constructed from a flipped 'n'. From a designers point of view, this sounds like a win (less work). However, such approaches can lead to rasterization issues, such as having the 'u' not sitting on the baseline at certain sizes after running the font through ttfautohint. 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, this problem can be fixed by using the "Decompose Transformed Components" filter.
🔥 FAIL: Check name table: FONT_SUBFAMILY_NAME entries.
🔥 FAIL: Check name table: TYPOGRAPHIC_SUBFAMILY_NAME entries.--- Rationale --- Requirements for the TYPOGRAPHIC_SUBFAMILY_NAME entries in the 'name' table.
🔥 FAIL: Check glyphs do not have components which are themselves components.--- Rationale --- There have been bugs rendering variable fonts with nested components. Additionally, some static fonts with nested components have been reported to have rendering and printing issues. For more info, see: * https://github.com/googlefonts/fontbakery/issues/2961 * https://github.com/arrowtype/recursive/issues/412
🔥 FAIL: Name table strings must not contain the string 'Reserved Font Name'.--- Rationale --- Some designers adopt the "Reserved Font Name" clause of the OFL license. This means that the original author reserves the rights to the family name and other people can only distribute modified versions using a different family name. Google Fonts published updates to the fonts in the collection in order to fix issues and/or implement further improvements to the fonts. It is important to keep the family name so that users of the webfonts can benefit from the updates. Since it would forbid such usage scenario, all families in the GFonts collection are required to not adopt the RFN clause. This check ensures "Reserved Font Name" is not mentioned in the name table.
🔥 FAIL: Font has correct post table version?--- Rationale --- Apple recommends against using 'post' table format 3 under most circumstances, as it can create problems with some printer drivers and PDF documents. The savings in disk space usually does not justify the potential loss in functionality. Source: https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6post.html The CFF2 table does not contain glyph names, so variable OTFs should be allowed to use post table version 2. This check expects: - Version 2 for TTF or OTF CFF2 Variable fonts - Version 3 for OTF
🔥 FAIL: Name table ID 6 (PostScript name) must be consistent across platforms.--- Rationale --- 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.
⚠ WARN: License URL matches License text on name table?--- Rationale --- A known license URL must be provided in the NameID 14 (LICENSE INFO URL) entry of the name table. The source of truth for this check is the licensing text found on the NameID 13 entry (LICENSE DESCRIPTION). The string snippets used for detecting licensing terms are: - "This Font Software is licensed under the SIL Open Font License, Version 1.1. This license is available with a FAQ at: https://scripts.sil.org/OFL" - "Licensed under the Apache License, Version 2.0" - "Licensed under the Ubuntu Font Licence 1.0." Currently accepted licenses are Apache or Open Font License. For a small set of legacy families the Ubuntu Font License may be acceptable as well. When in doubt, please choose OFL for new font projects.
⚠ WARN: Copyright notice on METADATA.pb should not contain 'Reserved Font Name'.
⚠ WARN: Combined length of family and style must not exceed 27 characters.--- Rationale --- 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
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: A static fonts directory with at least two fonts must accompany variable fonts--- Rationale --- Variable font family directories kept in the google/fonts git repo may include a static/ subdir containing static fonts. These files are meant to be served for users that still lack support for variable fonts in their web browsers.
⚠ WARN: Ensure fonts have ScriptLangTags declared on the 'meta' table.--- Rationale --- 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: Check font contains no unreachable glyphs--- Rationale --- Glyphs are either accessible directly through Unicode codepoints or through substitution rules. Any glyphs not accessible by either of these means are redundant and serve only to increase the font's file size.
⚠ WARN: Does the font have a DSIG table?--- Rationale --- 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 dummy DSIG table by running one of the helper scripts provided at https://github.com/googlefonts/gftools Reference: https://github.com/googlefonts/fontbakery/issues/1845
⚠ WARN: Check glyphs in mark glyph class are non-spacing.--- Rationale --- 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: Check mark characters are in GDEF mark glyph class.--- Rationale --- Mark characters should be in the GDEF mark glyph class.
Summary
Note: The following loglevels were omitted in this report:
|
RosaWagner
added
--- Live
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Taken from the upstream repo https://github.com/adobe-fonts/source-code-pro at release https://github.com/adobe-fonts/source-code-pro/releases/tag/2.038R-ro%2F1.058R-it%2F1.018R-VAR
fixes #82