Playfair Display v1.203 (stat fix) #3649
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
Fontbakery reportFontbakery version: 0.8.0 [1] Family checks⚠ WARN: Is the command `ftxvalidator` (Apple Font Tool Suite) available?--- Rationale --- There's no reasonable (and legal) way to run the command `ftxvalidator` of the Apple Font Tool Suite on a non-macOS machine. I.e. on GNU+Linux or Windows etc. If Font Bakery is not running on an OSX machine, the machine running Font Bakery could access `ftxvalidator` on OSX, e.g. via ssh or a remote procedure call (rpc). There's an ssh example implementation at: https://github.com/googlefonts/fontbakery/blob/main/prebuilt/workarounds /ftxvalidator/ssh-implementation/ftxvalidator
[16] PlayfairDisplay-Italic[wght].ttf🔥 FAIL: Check `Google Fonts Latin Core` glyph coverage.--- Rationale --- Google Fonts expects that fonts in its collection support at least the minimal set of characters defined in the `GF-latin-core` glyph-set.
🔥 FAIL: Stricter unitsPerEm criteria for Google Fonts.--- Rationale --- Even though the OpenType spec allows unitsPerEm to be any value between 16 and 16384, the Google Fonts project aims at a narrower set of reasonable values. The spec suggests usage of powers of two in order to get some performance improvements on legacy renderers, so those values are acceptable. But values of 500 or 1000 are also acceptable, with the added benefit that it makes upm math easier for designers, while the performance hit of not using a power of two is most likely negligible nowadays. Additionally, values above 2048 would likely result in unreasonable filesize increases.
🔥 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: Check if the vertical metrics of a family are similar to the same family hosted on Google Fonts.--- Rationale --- If the family already exists on Google Fonts, we need to ensure that the checked family's vertical metrics are similar. This check will test the following schema which was outlined in Fontbakery issue #1162 [1]: - The family should visually have the same vertical metrics as the Regular style hosted on Google Fonts. - If the family on Google Fonts has differing hhea and typo metrics, the family being checked should use the typo metrics for both the hhea and typo entries. - If the family on Google Fonts has use typo metrics not enabled and the family being checked has it enabled, the hhea and typo metrics should use the family on Google Fonts winAscent and winDescent values. - If the upms differ, the values must be scaled so the visual appearance is the same. [1] https://github.com/googlefonts/fontbakery/issues/1162
🔥 FAIL: Ensure METADATA.pb does not use escaped strings.--- Rationale --- In some cases we've seen designer names and other fields with escaped strings in METADATA files. Nowadays the strings can be full unicode strings and do not need escaping.
🔥 FAIL: Ensure variable fonts include an avar table.--- Rationale --- Most variable fonts should include an avar table to correctly define axes progression rates. For example, a weight axis from 0% to 100% doesn't map directly to 100 to 1000, because a 10% progression from 0% may be too much to define the 200, while 90% may be too little to define the 900. If the progression rates of axes is linear, this check can be ignored. Fontmake will also skip adding an avar table if the progression rates are linear. However, we still recommend designers visually proof each instance is at the desired weight, width etc.
⚠ WARN: 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.
⚠ 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: Are there caret positions declared for every ligature?--- Rationale --- All ligatures in a font must have corresponding caret (text cursor) positions defined in the GDEF table, otherwhise, users may experience issues with caret rendering. If using GlyphsApp or UFOs, ligature carets can be defined as anchors with names starting with 'caret_'. These can be compiled with fontmake as of version v2.4.0.
⚠ WARN: Is there kerning info for non-ligated sequences?--- Rationale --- Fonts with ligatures should have kerning on the corresponding non-ligated sequences for text where ligatures aren't used (eg https://github.com/impallari/Raleway/issues/14).
⚠ WARN: METADATA.pb: Designer is listed with the correct name on the Google Fonts catalog of designers?
⚠ 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: Checking unitsPerEm value is reasonable.--- Rationale --- According to the OpenType spec: The value of unitsPerEm at the head table must be a value between 16 and 16384. Any value in this range is valid. In fonts that have TrueType outlines, a power of 2 is recommended as this allows performance optimizations in some rasterizers. But 1000 is a commonly used value. And 2000 may become increasingly more common on Variable Fonts.
⚠ WARN: Check mark characters are in GDEF mark glyph class--- Rationale --- Mark characters should be in the GDEF mark glyph class.
[15] PlayfairDisplay[wght].ttf🔥 FAIL: Check `Google Fonts Latin Core` glyph coverage.--- Rationale --- Google Fonts expects that fonts in its collection support at least the minimal set of characters defined in the `GF-latin-core` glyph-set.
🔥 FAIL: Stricter unitsPerEm criteria for Google Fonts.--- Rationale --- Even though the OpenType spec allows unitsPerEm to be any value between 16 and 16384, the Google Fonts project aims at a narrower set of reasonable values. The spec suggests usage of powers of two in order to get some performance improvements on legacy renderers, so those values are acceptable. But values of 500 or 1000 are also acceptable, with the added benefit that it makes upm math easier for designers, while the performance hit of not using a power of two is most likely negligible nowadays. Additionally, values above 2048 would likely result in unreasonable filesize increases.
🔥 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: Check if the vertical metrics of a family are similar to the same family hosted on Google Fonts.--- Rationale --- If the family already exists on Google Fonts, we need to ensure that the checked family's vertical metrics are similar. This check will test the following schema which was outlined in Fontbakery issue #1162 [1]: - The family should visually have the same vertical metrics as the Regular style hosted on Google Fonts. - If the family on Google Fonts has differing hhea and typo metrics, the family being checked should use the typo metrics for both the hhea and typo entries. - If the family on Google Fonts has use typo metrics not enabled and the family being checked has it enabled, the hhea and typo metrics should use the family on Google Fonts winAscent and winDescent values. - If the upms differ, the values must be scaled so the visual appearance is the same. [1] https://github.com/googlefonts/fontbakery/issues/1162
🔥 FAIL: Ensure METADATA.pb does not use escaped strings.--- Rationale --- In some cases we've seen designer names and other fields with escaped strings in METADATA files. Nowadays the strings can be full unicode strings and do not need escaping.
🔥 FAIL: Ensure variable fonts include an avar table.--- Rationale --- Most variable fonts should include an avar table to correctly define axes progression rates. For example, a weight axis from 0% to 100% doesn't map directly to 100 to 1000, because a 10% progression from 0% may be too much to define the 200, while 90% may be too little to define the 900. If the progression rates of axes is linear, this check can be ignored. Fontmake will also skip adding an avar table if the progression rates are linear. However, we still recommend designers visually proof each instance is at the desired weight, width etc.
⚠ WARN: 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.
⚠ 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: Are there caret positions declared for every ligature?--- Rationale --- All ligatures in a font must have corresponding caret (text cursor) positions defined in the GDEF table, otherwhise, users may experience issues with caret rendering. If using GlyphsApp or UFOs, ligature carets can be defined as anchors with names starting with 'caret_'. These can be compiled with fontmake as of version v2.4.0.
⚠ WARN: Is there kerning info for non-ligated sequences?--- Rationale --- Fonts with ligatures should have kerning on the corresponding non-ligated sequences for text where ligatures aren't used (eg https://github.com/impallari/Raleway/issues/14).
⚠ WARN: METADATA.pb: Designer is listed with the correct name on the Google Fonts catalog of designers?
⚠ 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: Checking unitsPerEm value is reasonable.--- Rationale --- According to the OpenType spec: The value of unitsPerEm at the head table must be a value between 16 and 16384. Any value in this range is valid. In fonts that have TrueType outlines, a power of 2 is recommended as this allows performance optimizations in some rasterizers. But 1000 is a commonly used value. And 2000 may become increasingly more common on Variable Fonts.
⚠ 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:
|
|
Strange… Word see two Regular entries, but the fonts seems fine. |
|
Can you double check that your cache is cleared? |
Are you using a Mac? Appears to be OK here. |
|
@kenmcd yeah, Mac Word has some, ah, unique behaviors with variable fonts, that we’re trying to fix :). |
Yes, I have seen you guys "discussing" (joking) about it as a sort of worst case testing platform. ;-) |
|
Clearing Word's cache folders¹ is normally enough, but you're right, more needed to be done. It's okay now, sorry for the false alarm. ¹: (@kenmcd Word for Windows doesn't use the |
This was referenced Aug 4, 2021
|
All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the ℹ️ Googlers: Go here for more info. |
|
Updated the fonts (rebased too).
QA looks clean as a whistle. |
|
All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the ℹ️ Googlers: Go here for more info. |
|
@googlebot I consent. |
|
All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the ℹ️ Googlers: Go here for more info. |
Fontbakery reportFontbakery version: 0.8.1 [1] Family checks⚠ WARN: Is the command `ftxvalidator` (Apple Font Tool Suite) available?--- Rationale --- There's no reasonable (and legal) way to run the command `ftxvalidator` of the Apple Font Tool Suite on a non-macOS machine. I.e. on GNU+Linux or Windows etc. If Font Bakery is not running on an OSX machine, the machine running Font Bakery could access `ftxvalidator` on OSX, e.g. via ssh or a remote procedure call (rpc). There's an ssh example implementation at: https://github.com/googlefonts/fontbakery/blob/main/prebuilt/workarounds /ftxvalidator/ssh-implementation/ftxvalidator
[15] PlayfairDisplay-Italic[wght].ttf🔥 FAIL: Check `Google Fonts Latin Core` glyph coverage.--- Rationale --- Google Fonts expects that fonts in its collection support at least the minimal set of characters defined in the `GF-latin-core` glyph-set.
🔥 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: Ensure variable fonts include an avar table.--- Rationale --- Most variable fonts should include an avar table to correctly define axes progression rates. For example, a weight axis from 0% to 100% doesn't map directly to 100 to 1000, because a 10% progression from 0% may be too much to define the 200, while 90% may be too little to define the 900. If the progression rates of axes is linear, this check can be ignored. Fontmake will also skip adding an avar table if the progression rates are linear. However, we still recommend designers visually proof each instance is at the desired weight, width etc.
⚠ WARN: 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.
⚠ 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: Are there caret positions declared for every ligature?--- Rationale --- All ligatures in a font must have corresponding caret (text cursor) positions defined in the GDEF table, otherwhise, users may experience issues with caret rendering. If using GlyphsApp or UFOs, ligature carets can be defined as anchors with names starting with 'caret_'. These can be compiled with fontmake as of version v2.4.0.
⚠ WARN: Is there kerning info for non-ligated sequences?--- Rationale --- Fonts with ligatures should have kerning on the corresponding non-ligated sequences for text where ligatures aren't used (eg https://github.com/impallari/Raleway/issues/14).
⚠ 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: METADATA.pb: Designers are listed correctly on the Google Fonts catalog?--- Rationale --- Google Fonts has a catalog of designers. This check ensures that the online entries of the catalog can be found based on the designer names listed on the METADATA.pb file. It also validates the URLs and file formats are all correctly set.
⚠ 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: Each font in set of sibling families must have the same set of vertical metrics values.--- Rationale --- We may want all fonts within a super-family (all sibling families) to have the same vertical metrics so their line spacing is consistent across the super-family. This is an experimental extended version of com.google.fonts/check/family/vertical_metrics and for now it will only result in WARNs.
⚠ 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 mark characters are in GDEF mark glyph class.--- Rationale --- Mark characters should be in the GDEF mark glyph class.
[14] PlayfairDisplay[wght].ttf🔥 FAIL: Check `Google Fonts Latin Core` glyph coverage.--- Rationale --- Google Fonts expects that fonts in its collection support at least the minimal set of characters defined in the `GF-latin-core` glyph-set.
🔥 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: Ensure variable fonts include an avar table.--- Rationale --- Most variable fonts should include an avar table to correctly define axes progression rates. For example, a weight axis from 0% to 100% doesn't map directly to 100 to 1000, because a 10% progression from 0% may be too much to define the 200, while 90% may be too little to define the 900. If the progression rates of axes is linear, this check can be ignored. Fontmake will also skip adding an avar table if the progression rates are linear. However, we still recommend designers visually proof each instance is at the desired weight, width etc.
⚠ WARN: 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.
⚠ 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: Are there caret positions declared for every ligature?--- Rationale --- All ligatures in a font must have corresponding caret (text cursor) positions defined in the GDEF table, otherwhise, users may experience issues with caret rendering. If using GlyphsApp or UFOs, ligature carets can be defined as anchors with names starting with 'caret_'. These can be compiled with fontmake as of version v2.4.0.
⚠ WARN: Is there kerning info for non-ligated sequences?--- Rationale --- Fonts with ligatures should have kerning on the corresponding non-ligated sequences for text where ligatures aren't used (eg https://github.com/impallari/Raleway/issues/14).
⚠ 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: METADATA.pb: Designers are listed correctly on the Google Fonts catalog?--- Rationale --- Google Fonts has a catalog of designers. This check ensures that the online entries of the catalog can be found based on the designer names listed on the METADATA.pb file. It also validates the URLs and file formats are all correctly set.
⚠ 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: Each font in set of sibling families must have the same set of vertical metrics values.--- Rationale --- We may want all fonts within a super-family (all sibling families) to have the same vertical metrics so their line spacing is consistent across the super-family. This is an experimental extended version of com.google.fonts/check/family/vertical_metrics and for now it will only result in WARNs.
⚠ 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 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:
|
|
Per our discussion earlier, would it be better for me to adjust the position of the masters to follow more expected intervals? Or leave it as is? |
|
The end result is the import one, and it has to be the same as already published. So I don't think you should bother here. |
|
@aaronbell can you make this PR only about Playfait Display ? It has 1710 files in it. |
- tuned UPM back to 1000 - adjusted vertical metrics to match original.
aaronbell
force-pushed
the
playfair_stat
branch
from
a0f293e
to
453fcff
Compare
|
Rebased the PR, and removed some files that shouldn't have been added |
Fontbakery reportFontbakery version: 0.8.2 [15] PlayfairDisplay-Italic[wght].ttf🔥 FAIL: Check `Google Fonts Latin Core` glyph coverage.--- Rationale --- Google Fonts expects that fonts in its collection support at least the minimal set of characters defined in the `GF-latin-core` glyph-set.
🔥 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: Ensure variable fonts include an avar table.--- Rationale --- Most variable fonts should include an avar table to correctly define axes progression rates. For example, a weight axis from 0% to 100% doesn't map directly to 100 to 1000, because a 10% progression from 0% may be too much to define the 200, while 90% may be too little to define the 900. If the progression rates of axes is linear, this check can be ignored. Fontmake will also skip adding an avar table if the progression rates are linear. However, we still recommend designers visually proof each instance is at the desired weight, width etc.
⚠ WARN: 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.
⚠ 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: Are there caret positions declared for every ligature?--- Rationale --- All ligatures in a font must have corresponding caret (text cursor) positions defined in the GDEF table, otherwhise, users may experience issues with caret rendering. If using GlyphsApp or UFOs, ligature carets can be defined as anchors with names starting with 'caret_'. These can be compiled with fontmake as of version v2.4.0.
⚠ WARN: Is there kerning info for non-ligated sequences?--- Rationale --- Fonts with ligatures should have kerning on the corresponding non-ligated sequences for text where ligatures aren't used (eg https://github.com/impallari/Raleway/issues/14).
⚠ 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: METADATA.pb: Designers are listed correctly on the Google Fonts catalog?--- Rationale --- Google Fonts has a catalog of designers. This check ensures that the online entries of the catalog can be found based on the designer names listed on the METADATA.pb file. It also validates the URLs and file formats are all correctly set.
⚠ 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: Each font in set of sibling families must have the same set of vertical metrics values.--- Rationale --- We may want all fonts within a super-family (all sibling families) to have the same vertical metrics so their line spacing is consistent across the super-family. This is an experimental extended version of com.google.fonts/check/family/vertical_metrics and for now it will only result in WARNs.
⚠ 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 mark characters are in GDEF mark glyph class.--- Rationale --- Mark characters should be in the GDEF mark glyph class.
[14] PlayfairDisplay[wght].ttf🔥 FAIL: Check `Google Fonts Latin Core` glyph coverage.--- Rationale --- Google Fonts expects that fonts in its collection support at least the minimal set of characters defined in the `GF-latin-core` glyph-set.
🔥 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: Ensure variable fonts include an avar table.--- Rationale --- Most variable fonts should include an avar table to correctly define axes progression rates. For example, a weight axis from 0% to 100% doesn't map directly to 100 to 1000, because a 10% progression from 0% may be too much to define the 200, while 90% may be too little to define the 900. If the progression rates of axes is linear, this check can be ignored. Fontmake will also skip adding an avar table if the progression rates are linear. However, we still recommend designers visually proof each instance is at the desired weight, width etc.
⚠ WARN: 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.
⚠ 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: Are there caret positions declared for every ligature?--- Rationale --- All ligatures in a font must have corresponding caret (text cursor) positions defined in the GDEF table, otherwhise, users may experience issues with caret rendering. If using GlyphsApp or UFOs, ligature carets can be defined as anchors with names starting with 'caret_'. These can be compiled with fontmake as of version v2.4.0.
⚠ WARN: Is there kerning info for non-ligated sequences?--- Rationale --- Fonts with ligatures should have kerning on the corresponding non-ligated sequences for text where ligatures aren't used (eg https://github.com/impallari/Raleway/issues/14).
⚠ 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: METADATA.pb: Designers are listed correctly on the Google Fonts catalog?--- Rationale --- Google Fonts has a catalog of designers. This check ensures that the online entries of the catalog can be found based on the designer names listed on the METADATA.pb file. It also validates the URLs and file formats are all correctly set.
⚠ 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: Each font in set of sibling families must have the same set of vertical metrics values.--- Rationale --- We may want all fonts within a super-family (all sibling families) to have the same vertical metrics so their line spacing is consistent across the super-family. This is an experimental extended version of com.google.fonts/check/family/vertical_metrics and for now it will only result in WARNs.
⚠ 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 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:
|
|
Oh no, looks like there is a positive kerning pair with group of i-n. Diff shows kerning regression in Italic. |
RosaWagner
added
-- Needs Upstream Resolution
Fixing bad kern in the italic variable font.
|
I've fixed the kern pair and reviewed the italics in general. Seems better now! |
Fontbakery reportFontbakery version: 0.8.2 [15] PlayfairDisplay-Italic[wght].ttf🔥 FAIL: Check `Google Fonts Latin Core` glyph coverage.--- Rationale --- Google Fonts expects that fonts in its collection support at least the minimal set of characters defined in the `GF-latin-core` glyph-set.
🔥 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: Ensure variable fonts include an avar table.--- Rationale --- Most variable fonts should include an avar table to correctly define axes progression rates. For example, a weight axis from 0% to 100% doesn't map directly to 100 to 1000, because a 10% progression from 0% may be too much to define the 200, while 90% may be too little to define the 900. If the progression rates of axes is linear, this check can be ignored. Fontmake will also skip adding an avar table if the progression rates are linear. However, we still recommend designers visually proof each instance is at the desired weight, width etc.
⚠ WARN: 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.
⚠ 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: Are there caret positions declared for every ligature?--- Rationale --- All ligatures in a font must have corresponding caret (text cursor) positions defined in the GDEF table, otherwhise, users may experience issues with caret rendering. If using GlyphsApp or UFOs, ligature carets can be defined as anchors with names starting with 'caret_'. These can be compiled with fontmake as of version v2.4.0.
⚠ WARN: Is there kerning info for non-ligated sequences?--- Rationale --- Fonts with ligatures should have kerning on the corresponding non-ligated sequences for text where ligatures aren't used (eg https://github.com/impallari/Raleway/issues/14).
⚠ 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: METADATA.pb: Designers are listed correctly on the Google Fonts catalog?--- Rationale --- Google Fonts has a catalog of designers. This check ensures that the online entries of the catalog can be found based on the designer names listed on the METADATA.pb file. It also validates the URLs and file formats are all correctly set.
⚠ 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: Each font in set of sibling families must have the same set of vertical metrics values.--- Rationale --- We may want all fonts within a super-family (all sibling families) to have the same vertical metrics so their line spacing is consistent across the super-family. This is an experimental extended version of com.google.fonts/check/family/vertical_metrics and for now it will only result in WARNs.
⚠ 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 mark characters are in GDEF mark glyph class.--- Rationale --- Mark characters should be in the GDEF mark glyph class.
[14] PlayfairDisplay[wght].ttf🔥 FAIL: Check `Google Fonts Latin Core` glyph coverage.--- Rationale --- Google Fonts expects that fonts in its collection support at least the minimal set of characters defined in the `GF-latin-core` glyph-set.
🔥 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: Ensure variable fonts include an avar table.--- Rationale --- Most variable fonts should include an avar table to correctly define axes progression rates. For example, a weight axis from 0% to 100% doesn't map directly to 100 to 1000, because a 10% progression from 0% may be too much to define the 200, while 90% may be too little to define the 900. If the progression rates of axes is linear, this check can be ignored. Fontmake will also skip adding an avar table if the progression rates are linear. However, we still recommend designers visually proof each instance is at the desired weight, width etc.
⚠ WARN: 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.
⚠ 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: Are there caret positions declared for every ligature?--- Rationale --- All ligatures in a font must have corresponding caret (text cursor) positions defined in the GDEF table, otherwhise, users may experience issues with caret rendering. If using GlyphsApp or UFOs, ligature carets can be defined as anchors with names starting with 'caret_'. These can be compiled with fontmake as of version v2.4.0.
⚠ WARN: Is there kerning info for non-ligated sequences?--- Rationale --- Fonts with ligatures should have kerning on the corresponding non-ligated sequences for text where ligatures aren't used (eg https://github.com/impallari/Raleway/issues/14).
⚠ 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: METADATA.pb: Designers are listed correctly on the Google Fonts catalog?--- Rationale --- Google Fonts has a catalog of designers. This check ensures that the online entries of the catalog can be found based on the designer names listed on the METADATA.pb file. It also validates the URLs and file formats are all correctly set.
⚠ 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: Each font in set of sibling families must have the same set of vertical metrics values.--- Rationale --- We may want all fonts within a super-family (all sibling families) to have the same vertical metrics so their line spacing is consistent across the super-family. This is an experimental extended version of com.google.fonts/check/family/vertical_metrics and for now it will only result in WARNs.
⚠ 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 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
- Ready for Review
and removed
-- Needs Upstream Resolution
RosaWagner
added
--- to_production
I Small Fix
RosaWagner
added
I Small Fix
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.
Font repro updated to the UFR format (https://github.com/aaronbell/Playfair-Display).
PR'd to upstream.
Font files rebuilt.