Updating Roboto's STAT table to add the SemiBold instance #3791
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
This update has been implemented by running `gftools gen-stat` on the current version in GF. I've also pushed a PR to the upstream repro that implements this fix in the build script here: googlefonts/roboto-3-classic#92 As the font is only available through the releases process, I thought it easier to PR manually.
Fontbakery reportFontbakery version: 0.8.2 [1] Family checks🔥 FAIL: Does font file include unacceptable control character glyphs?--- Rationale --- Use of some unacceptable control characters in the U+0000 - U+001F range can lead to rendering issues on some platforms. Acceptable control characters are defined as .null (U+0000) and CR (U+000D) for this test.
[22] Roboto-Italic[wdth,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: Check font has a license.
🔥 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: 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: Font enables smart dropout control in "prep" table instructions?--- Rationale ---
This setup is meant to ensure consistent rendering quality for fonts across all
devices (with different rendering/hinting capabilities).
Below is the snippet of instructions we expect to see in the fonts:
B8 01 FF PUSHW 0x01FF
85 SCANCTRL (unconditinally turn on
dropout control mode)
B0 04 PUSHB 0x04
8D SCANTYPE (enable smart dropout control)
"Smart dropout control" means activating rules 1, 2 and 5:
Rule 1: If a pixel's center falls within the glyph outline,
that pixel is turned on.
Rule 2: If a contour falls exactly on a pixel's center,
that pixel is turned on.
Rule 5: If a scan line between two adjacent pixel centers
(either vertical or horizontal) is intersected
by both an on-Transition contour and an off-Transition
contour and neither of the pixels was already turned on
by rules 1 and 2, turn on the pixel which is closer to
the midpoint between the on-Transition contour and
off-Transition contour. This is "Smart" dropout control.
For more detailed info (such as other rules not enabled in this snippet), please
refer to the TrueType Instruction Set documentation.
🔥 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: Check variable font instances have correct names
Further info can be found in our spec https://github.com/googlefonts/gf-docs/tree/main/Spec#fvar-instances [code: bad-instance-names] 🔥 FAIL: 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.
🔥 FAIL: OS/2.fsSelection bit 7 (USE_TYPO_METRICS) is set in all fonts.--- Rationale --- All fonts on the Google Fonts collection should have OS/2.fsSelection bit 7 (USE_TYPO_METRICS) set. This requirement is part of the vertical metrics scheme established as a Google Fonts policy aiming at a common ground supported by all major font rendering environments. For more details, read: https://github.com/googlefonts/gf-docs/blob/main/VerticalMetrics/README.md Below is the portion of that document that is most relevant to this check: Use_Typo_Metrics must be enabled. This will force MS Applications to use the OS/2 Typo values instead of the Win values. By doing this, we can freely set the Win values to avoid clipping and control the line height with the typo values. It has the added benefit of future line height compatibility. When a new script is added, we simply change the Win values to the new yMin and yMax, without needing to worry if the line height have changed.
🔥 FAIL: Checking OS/2 usWinAscent & usWinDescent.--- Rationale --- A font's winAscent and winDescent values should be greater than the head table's yMax, abs(yMin) values. If they are less than these values, clipping can occur on Windows platforms (https://github.com/RedHatBrand/Overpass/issues/33). If the font includes tall/deep writing systems such as Arabic or Devanagari, the winAscent and winDescent can be greater than the yMax and abs(yMin) to accommodate vowel marks. When the win Metrics are significantly greater than the upm, the linespacing can appear too loose. To counteract this, enabling the OS/2 fsSelection bit 7 (Use_Typo_Metrics), will force Windows to use the OS/2 typo values instead. This means the font developer can control the linespacing with the typo values, whilst avoiding clipping by setting the win values to values greater than the yMax and abs(yMin).
🔥 FAIL: Checking OS/2 Metrics match hhea Metrics.--- Rationale --- OS/2 and hhea vertical metric values should match. This will produce the same linespacing on Mac, GNU+Linux and Windows. - Mac OS X uses the hhea values. - Windows uses OS/2 or Win, depending on the OS or fsSelection bit value. When OS/2 and hhea vertical metrics match, the same linespacing results on macOS, GNU+Linux and Windows. Unfortunately as of 2018, Google Fonts has released many fonts with vertical metrics that don't match in this way. When we fix this issue in these existing families, we will create a visible change in line/paragraph layout for either Windows or macOS users, which will upset some of them. But we have a duty to fix broken stuff, and inconsistent paragraph layout is unacceptably broken when it is possible to avoid it. If users complain and prefer the old broken version, they have the freedom to take care of their own situation.
🔥 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
⚠ 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: Is the Grid-fitting and Scan-conversion Procedure ('gasp') table set to optimize rendering?--- Rationale --- Traditionally version 0 'gasp' tables were set so that font sizes below 8 ppem had no grid fitting but did have antialiasing. From 9-16 ppem, just grid fitting. And fonts above 17ppem had both antialiasing and grid fitting toggled on. The use of accelerated graphics cards and higher resolution screens make this approach obsolete. Microsoft's DirectWrite pushed this even further with much improved rendering built into the OS and apps. In this scenario it makes sense to simply toggle all 4 flags ON for all font sizes.
⚠ 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: Ensure Stylistic Sets have description.--- Rationale --- Stylistic sets should provide description text. Programs such as InDesign, TextEdit and Inkscape use that info to display to the users so that they know what a given stylistic set offers.
⚠ 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 if OS/2 xAvgCharWidth is correct.
⚠ WARN: Checking Vertical Metric Linegaps.
⚠ WARN: Check mark characters are in GDEF mark glyph class.--- Rationale --- Mark characters should be in the GDEF mark glyph class.
[22] Roboto[wdth,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: Check font has a license.
🔥 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: METADATA.pb font.full_name and font.post_script_name fields have equivalent values ?
🔥 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: Font enables smart dropout control in "prep" table instructions?--- Rationale ---
This setup is meant to ensure consistent rendering quality for fonts across all
devices (with different rendering/hinting capabilities).
Below is the snippet of instructions we expect to see in the fonts:
B8 01 FF PUSHW 0x01FF
85 SCANCTRL (unconditinally turn on
dropout control mode)
B0 04 PUSHB 0x04
8D SCANTYPE (enable smart dropout control)
"Smart dropout control" means activating rules 1, 2 and 5:
Rule 1: If a pixel's center falls within the glyph outline,
that pixel is turned on.
Rule 2: If a contour falls exactly on a pixel's center,
that pixel is turned on.
Rule 5: If a scan line between two adjacent pixel centers
(either vertical or horizontal) is intersected
by both an on-Transition contour and an off-Transition
contour and neither of the pixels was already turned on
by rules 1 and 2, turn on the pixel which is closer to
the midpoint between the on-Transition contour and
off-Transition contour. This is "Smart" dropout control.
For more detailed info (such as other rules not enabled in this snippet), please
refer to the TrueType Instruction Set documentation.
🔥 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: Check variable font instances have correct names
Further info can be found in our spec https://github.com/googlefonts/gf-docs/tree/main/Spec#fvar-instances [code: bad-instance-names] 🔥 FAIL: 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.
🔥 FAIL: OS/2.fsSelection bit 7 (USE_TYPO_METRICS) is set in all fonts.--- Rationale --- All fonts on the Google Fonts collection should have OS/2.fsSelection bit 7 (USE_TYPO_METRICS) set. This requirement is part of the vertical metrics scheme established as a Google Fonts policy aiming at a common ground supported by all major font rendering environments. For more details, read: https://github.com/googlefonts/gf-docs/blob/main/VerticalMetrics/README.md Below is the portion of that document that is most relevant to this check: Use_Typo_Metrics must be enabled. This will force MS Applications to use the OS/2 Typo values instead of the Win values. By doing this, we can freely set the Win values to avoid clipping and control the line height with the typo values. It has the added benefit of future line height compatibility. When a new script is added, we simply change the Win values to the new yMin and yMax, without needing to worry if the line height have changed.
🔥 FAIL: Checking OS/2 usWinAscent & usWinDescent.--- Rationale --- A font's winAscent and winDescent values should be greater than the head table's yMax, abs(yMin) values. If they are less than these values, clipping can occur on Windows platforms (https://github.com/RedHatBrand/Overpass/issues/33). If the font includes tall/deep writing systems such as Arabic or Devanagari, the winAscent and winDescent can be greater than the yMax and abs(yMin) to accommodate vowel marks. When the win Metrics are significantly greater than the upm, the linespacing can appear too loose. To counteract this, enabling the OS/2 fsSelection bit 7 (Use_Typo_Metrics), will force Windows to use the OS/2 typo values instead. This means the font developer can control the linespacing with the typo values, whilst avoiding clipping by setting the win values to values greater than the yMax and abs(yMin).
🔥 FAIL: Checking OS/2 Metrics match hhea Metrics.--- Rationale --- OS/2 and hhea vertical metric values should match. This will produce the same linespacing on Mac, GNU+Linux and Windows. - Mac OS X uses the hhea values. - Windows uses OS/2 or Win, depending on the OS or fsSelection bit value. When OS/2 and hhea vertical metrics match, the same linespacing results on macOS, GNU+Linux and Windows. Unfortunately as of 2018, Google Fonts has released many fonts with vertical metrics that don't match in this way. When we fix this issue in these existing families, we will create a visible change in line/paragraph layout for either Windows or macOS users, which will upset some of them. But we have a duty to fix broken stuff, and inconsistent paragraph layout is unacceptably broken when it is possible to avoid it. If users complain and prefer the old broken version, they have the freedom to take care of their own situation.
🔥 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
⚠ 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: Is the Grid-fitting and Scan-conversion Procedure ('gasp') table set to optimize rendering?--- Rationale --- Traditionally version 0 'gasp' tables were set so that font sizes below 8 ppem had no grid fitting but did have antialiasing. From 9-16 ppem, just grid fitting. And fonts above 17ppem had both antialiasing and grid fitting toggled on. The use of accelerated graphics cards and higher resolution screens make this approach obsolete. Microsoft's DirectWrite pushed this even further with much improved rendering built into the OS and apps. In this scenario it makes sense to simply toggle all 4 flags ON for all font sizes.
⚠ 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: Ensure Stylistic Sets have description.--- Rationale --- Stylistic sets should provide description text. Programs such as InDesign, TextEdit and Inkscape use that info to display to the users so that they know what a given stylistic set offers.
⚠ 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 Vertical Metric Linegaps.
⚠ 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:
|
|
I'll ask Dave and Marc about it, but I guess we should be in sync with https://github.com/googlefonts/roboto and fix all these fails. |
|
You cannot fix the fails since the v2.138 also has these fails. We want it to match the older version as much as possible. |
|
Yeah, in reading through the discussions on the Roboto repro, I thought it best to leave things AS-IS as much as possible for fear of breaking something. 🙈 |
|
@m4rc1e even winAscent and winDecent? |
RosaWagner
added
- Ready for Review
and removed
-- Needs manager's opinion
|
Roboto requires special handling due to its status as the Android UI font.
Marc please take this forwards
|
|
We wait for this one #2876 to be push to production before pushing this PR |
RosaWagner
added
I Small Fix
|
Closing this PR since it is in conflict and Marc working on Roboto. |
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.
This update has been implemented by running
gftools gen-staton the current version in GF.I've also pushed a PR to the upstream repro that implements this fix in the build script here:
googlefonts/roboto-3-classic#92
As the font is only available through the releases process, I thought it easier to PR manually.