Yrsa: Version 2.004 added #4079
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
* Yrsa Version 2.004 taken from the upstream repo https://github.com/rosettatype/yrsa-rasa.git at commit rosettatype/yrsa-rasa@ec1d6aa.
Fontbakery reportFontbakery version: 0.8.3 [15] Yrsa-Italic[wght].ttf🔥 FAIL: Does DESCRIPTION file contain broken links?--- Rationale --- The snippet of HTML in the DESCRIPTION.en_us.html file is added to the font family webpage on the Google Fonts website. For that reason, all hyperlinks in it must be properly working.
🔥 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: DESCRIPTION.en_us.html should end in a linebreak.--- Rationale --- Some older text-handling tools sometimes misbehave if the last line of data in a text file is not terminated with a newline character (also known as '\n'). We know that this is a very small detail, but for the sake of keeping all DESCRIPTION.en_us.html files uniformly formatted throughout the GFonts collection, we chose to adopt the practice of placing this final linebreak char on them.
⚠ 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: 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: Font has **proper** whitespace glyph names?--- Rationale --- This check enforces adherence to recommended whitespace (codepoints 0020 and 00A0) glyph names according to the Adobe Glyph List.
⚠ WARN: Glyph names are all valid?--- Rationale --- Microsoft's recommendations for OpenType Fonts states the following: 'NOTE: The PostScript glyph name must be no longer than 31 characters, include only uppercase or lowercase English letters, European digits, the period or the underscore, i.e. from the set [A-Za-z0-9_.] and should start with a letter, except the special glyph name ".notdef" which starts with a period.' https://docs.microsoft.com/en-us/typography/opentype/spec/recom#post-table In practice, though, particularly in modern environments, glyph names can be as long as 63 characters. According to the "Adobe Glyph List Specification" available at: https://github.com/adobe-type-tools/agl-specification
⚠ 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: Checking Vertical Metric Linegaps.
⚠ 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.
⚠ WARN: Check GDEF mark glyph class doesn't have characters that are not marks.--- Rationale --- Glyphs in the GDEF mark glyph class become non-spacing and may be repositioned if they have mark anchors. Only combining mark glyphs should be in that class. Any non-mark glyph must not be in that class, in particular spacing glyphs.
[12] Yrsa[wght].ttf🔥 FAIL: Does DESCRIPTION file contain broken links?--- Rationale --- The snippet of HTML in the DESCRIPTION.en_us.html file is added to the font family webpage on the Google Fonts website. For that reason, all hyperlinks in it must be properly working.
🔥 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: DESCRIPTION.en_us.html should end in a linebreak.--- Rationale --- Some older text-handling tools sometimes misbehave if the last line of data in a text file is not terminated with a newline character (also known as '\n'). We know that this is a very small detail, but for the sake of keeping all DESCRIPTION.en_us.html files uniformly formatted throughout the GFonts collection, we chose to adopt the practice of placing this final linebreak char on them.
⚠ 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: 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: Font has **proper** whitespace glyph names?--- Rationale --- This check enforces adherence to recommended whitespace (codepoints 0020 and 00A0) glyph names according to the Adobe Glyph List.
⚠ WARN: Glyph names are all valid?--- Rationale --- Microsoft's recommendations for OpenType Fonts states the following: 'NOTE: The PostScript glyph name must be no longer than 31 characters, include only uppercase or lowercase English letters, European digits, the period or the underscore, i.e. from the set [A-Za-z0-9_.] and should start with a letter, except the special glyph name ".notdef" which starts with a period.' https://docs.microsoft.com/en-us/typography/opentype/spec/recom#post-table In practice, though, particularly in modern environments, glyph names can be as long as 63 characters. According to the "Adobe Glyph List Specification" available at: https://github.com/adobe-type-tools/agl-specification
⚠ 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: Checking Vertical Metric Linegaps.
⚠ 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:
|
|
Looks good. However, what's up with the fractions?
Seems like they've all been decremented by 1 |
|
I guess it's this rosettatype/yrsa-rasa#27? |
|
Exactly |
m4rc1e
added
--- to sandbox
and removed
- Ready for Review
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.
5af62b0: [gftools-packager] Yrsa: Version 2.004 added
753a081: [gftools-packager] ofl/yrsa remove METADATA "source". #2587