Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rokkitt v3.103 (stat fix) #3663

Merged
merged 1 commit into from
Aug 10, 2021
Merged

Rokkitt v3.103 (stat fix) #3663

merged 1 commit into from
Aug 10, 2021

Conversation

aaronbell
Copy link
Collaborator

Font repro updated to the UFR format (https://github.com/googlefonts/RokkittFont).
Font files rebuilt.

@aaronbell
Copy link
Collaborator Author

Fontbakery report

Fontbakery 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
  • WARN Could not find ftxvalidator. [code: ftxvalidator-available]

[8] Rokkitt[wght].ttf
🔥 FAIL: METADATA.pb: Designer is listed with the correct name on the Google Fonts catalog of designers?
WARN: Checking OS/2 achVendID.
--- Rationale ---
Microsoft keeps a list of font vendors and their respective contact info. This
list is updated regularly and is indexed by a 4-char "Vendor ID" which is stored
in the achVendID field of the OS/2 table.
Registering your ID is not mandatory, but it is a good practice since some
applications may display the type designer / type foundry contact info on some
dialog and also because that info will be visible on Microsoft's website:
https://docs.microsoft.com/en-us/typography/vendors/
This check verifies whether or not a given font's vendor ID is registered in
that list or if it has some of the default values used by the most common font
editors.
Each new FontBakery release includes a cached copy of that list of vendor IDs.
If you registered recently, you're safe to ignore warnings emitted by this
check, since your ID will soon be included in one of our upcoming releases.
  • WARN OS/2 VendorID value 'NEWT' is not yet recognized. If you registered it recently, then it's safe to ignore this warning message. Otherwise, you should set it to your own unique 4 character code, and register it with Microsoft at https://www.microsoft.com/typography/links/vendorlist.aspx
    [code: unknown]
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 Please consider using HTTPS URLs at name table entry [plat=3, enc=1, name=13] [code: http-in-description]
  • WARN For now we're still accepting http URLs, but you should consider using https instead.
    [code: http]
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 Please consider using HTTPS URLs at name table entry [plat=3, enc=1, name=13] [code: http-in-description]
  • WARN Please consider using HTTPS URLs at name table entry [plat=3, enc=1, name=13] [code: http-in-description]
  • WARN Please consider using HTTPS URLs at name table entry [plat=3, enc=1, name=13] [code: http-in-description]
  • WARN Please consider using HTTPS URLs at name table entry [plat=3, enc=1, name=14] [code: http-in-license-info]
  • WARN For now we're still accepting http URLs, but you should consider using https instead.
    [code: http]
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 This font lacks caret position values for ligature glyphs on its GDEF table. [code: lacks-caret-pos]
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 GPOS table lacks kerning info for the following non-ligated sequences:

    • f + f
    • f + i

    [code: lacks-kern-info]

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 This font file does not have a 'meta' table. [code: lacks-meta-table]
WARN: Are there any misaligned on-curve points?
--- Rationale ---
This check heuristically looks for on-curve points which are close to, but do
not sit on, significant boundary coordinates. For example, a point which has a
Y-coordinate of 1 or -1 might be a misplaced baseline point. As well as the
baseline, here we also check for points near the x-height (but only for lower
case Latin letters), cap-height, ascender and descender Y coordinates.
Not all such misaligned curve points are a mistake, and sometimes the design may
call for points in locations near the boundaries. As this check is liable to
generate significant numbers of false positives, it will pass if there are more
than 100 reported misalignments.
  • WARN The following glyphs have on-curve points which have potentially incorrect y coordinates:
    • uni1EB2: X=341.5,Y=819.0 (should be at ascender 817?)
    • Eng: X=598.0,Y=-1.0 (should be at baseline 0?)
    • uni1E4E: X=213.0,Y=819.0 (should be at ascender 817?)
    • uni1E4E: X=303.0,Y=819.0 (should be at ascender 817?)
    • uni1E4E: X=406.0,Y=819.0 (should be at ascender 817?)
    • uni1E4E: X=495.0,Y=819.0 (should be at ascender 817?)
    • uni1E7A: X=215.5,Y=815.5 (should be at ascender 817?)
    • uni1E7A: X=280.5,Y=815.5 (should be at ascender 817?)
    • uni1E7A: X=408.0,Y=815.5 (should be at ascender 817?)
    • uni1E7A: X=472.5,Y=815.5 (should be at ascender 817?) and 84 more. [code: found-misalignments]

Summary

💔 ERROR 🔥 FAIL ⚠ WARN 💤 SKIP ℹ INFO 🍞 PASS 🔎 DEBUG
0 1 8 47 10 147 0
0% 0% 4% 22% 5% 69% 0%

Note: The following loglevels were omitted in this report:

  • SKIP
  • INFO
  • PASS
  • DEBUG

@gf-bot
Copy link

gf-bot commented Aug 10, 2021

Fontbakery report

Fontbakery 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
  • WARN Could not find ftxvalidator. [code: ftxvalidator-available]

[8] Rokkitt[wght].ttf
🔥 FAIL: METADATA.pb: Designer is listed with the correct name on the Google Fonts catalog of designers?
WARN: Checking OS/2 achVendID.
--- Rationale ---
Microsoft keeps a list of font vendors and their respective contact info. This
list is updated regularly and is indexed by a 4-char "Vendor ID" which is stored
in the achVendID field of the OS/2 table.
Registering your ID is not mandatory, but it is a good practice since some
applications may display the type designer / type foundry contact info on some
dialog and also because that info will be visible on Microsoft's website:
https://docs.microsoft.com/en-us/typography/vendors/
This check verifies whether or not a given font's vendor ID is registered in
that list or if it has some of the default values used by the most common font
editors.
Each new FontBakery release includes a cached copy of that list of vendor IDs.
If you registered recently, you're safe to ignore warnings emitted by this
check, since your ID will soon be included in one of our upcoming releases.
  • WARN OS/2 VendorID value 'NEWT' is not yet recognized. If you registered it recently, then it's safe to ignore this warning message. Otherwise, you should set it to your own unique 4 character code, and register it with Microsoft at https://www.microsoft.com/typography/links/vendorlist.aspx
    [code: unknown]
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 Please consider using HTTPS URLs at name table entry [plat=3, enc=1, name=13] [code: http-in-description]
  • WARN For now we're still accepting http URLs, but you should consider using https instead.
    [code: http]
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 Please consider using HTTPS URLs at name table entry [plat=3, enc=1, name=13] [code: http-in-description]
  • WARN Please consider using HTTPS URLs at name table entry [plat=3, enc=1, name=13] [code: http-in-description]
  • WARN Please consider using HTTPS URLs at name table entry [plat=3, enc=1, name=13] [code: http-in-description]
  • WARN Please consider using HTTPS URLs at name table entry [plat=3, enc=1, name=14] [code: http-in-license-info]
  • WARN For now we're still accepting http URLs, but you should consider using https instead.
    [code: http]
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 This font lacks caret position values for ligature glyphs on its GDEF table. [code: lacks-caret-pos]
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 GPOS table lacks kerning info for the following non-ligated sequences:

    • f + f
    • f + i

    [code: lacks-kern-info]

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 This font file does not have a 'meta' table. [code: lacks-meta-table]
WARN: Are there any misaligned on-curve points?
--- Rationale ---
This check heuristically looks for on-curve points which are close to, but do
not sit on, significant boundary coordinates. For example, a point which has a
Y-coordinate of 1 or -1 might be a misplaced baseline point. As well as the
baseline, here we also check for points near the x-height (but only for lower
case Latin letters), cap-height, ascender and descender Y coordinates.
Not all such misaligned curve points are a mistake, and sometimes the design may
call for points in locations near the boundaries. As this check is liable to
generate significant numbers of false positives, it will pass if there are more
than 100 reported misalignments.
  • WARN The following glyphs have on-curve points which have potentially incorrect y coordinates:
    • uni1EB2: X=341.5,Y=819.0 (should be at ascender 817?)
    • Eng: X=598.0,Y=-1.0 (should be at baseline 0?)
    • uni1E4E: X=213.0,Y=819.0 (should be at ascender 817?)
    • uni1E4E: X=303.0,Y=819.0 (should be at ascender 817?)
    • uni1E4E: X=406.0,Y=819.0 (should be at ascender 817?)
    • uni1E4E: X=495.0,Y=819.0 (should be at ascender 817?)
    • uni1E7A: X=215.5,Y=815.5 (should be at ascender 817?)
    • uni1E7A: X=280.5,Y=815.5 (should be at ascender 817?)
    • uni1E7A: X=408.0,Y=815.5 (should be at ascender 817?)
    • uni1E7A: X=472.5,Y=815.5 (should be at ascender 817?) and 84 more. [code: found-misalignments]

Summary

💔 ERROR 🔥 FAIL ⚠ WARN 💤 SKIP ℹ INFO 🍞 PASS 🔎 DEBUG
0 1 8 47 10 147 0
0% 0% 4% 22% 5% 69% 0%

Note: The following loglevels were omitted in this report:

  • SKIP
  • INFO
  • PASS
  • DEBUG

@m4rc1e m4rc1e merged commit bfbea92 into main Aug 10, 2021
@m4rc1e m4rc1e deleted the rokkitt_stat branch August 10, 2021 09:44
m4rc1e added a commit that referenced this pull request Aug 10, 2021
m4rc1e added a commit that referenced this pull request Aug 10, 2021
@RosaWagner
Copy link
Contributor

This merge has been reverted and therefore there is nothing to push to sandbox there right?

@aaronbell
Copy link
Collaborator Author

Correct. I need to make some corrections and then will submit another PR.

@RosaWagner RosaWagner added I Small Fix bugs fixed but nothing added and removed I Font Upgrade labels Dec 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I Small Fix bugs fixed but nothing added
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants