Rosario v1.201 (stat fix)

[aaronbell]

Font repro updated to the UFR format (https://github.com/aaronbell/Rosario).
PR'd to upstream.

Font files rebuilt.

[aaronbell]

Fontbakery report

Fontbakery version: 0.8.0

[1] Family checks

⚠ WARN: Is the command `ftxvalidator` (Apple Font Tool Suite) available?

• com.google.fonts/check/ftxvalidator_is_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]

[9] Rosario-Italic[wght].ttf

🔥 FAIL: Checks METADATA.pb font.post_script_name matches postscript name declared on the name table.

• com.google.fonts/check/metadata/nameid/post_script_name

• 🔥 FAIL Unmatched postscript name in font: TTF has "Rosario-Italic" while METADATA.pb has "Rosario-LightItalic". [code: mismatch]

🔥 FAIL: METADATA.pb font.full_name value matches fullname declared on the name table?

• com.google.fonts/check/metadata/nameid/full_name

• 🔥 FAIL Unmatched fullname in font: TTF has "Rosario Italic" while METADATA.pb has "Rosario Light Italic". [code: mismatch]

🔥 FAIL: METADATA.pb font.name and font.full_name fields match the values declared on the name table?

• com.google.fonts/check/metadata/nameid/family_and_full_names

• 🔥 FAIL METADATA.pb: Fullname "Rosario Light Italic" does not match name table entry "Rosario Italic"! [code: fullname-mismatch]

⚠ WARN: Check copyright namerecords match license file.

• com.google.fonts/check/name/license

--- 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?

• com.google.fonts/check/name/license_url

--- 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?

• com.google.fonts/check/ligature_carets

--- 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?

• com.google.fonts/check/kerning_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
  • i + f
  • f + l
  • l + f
  • i + l

  [code: lacks-kern-info]

⚠ WARN: On a family update, the DESCRIPTION.en_us.html file should ideally also be updated.

• com.google.fonts/check/description/family_update

--- 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 The DESCRIPTION.en_us.html file in this family has not changed in comparison to the latest font release on the google/fonts github repo.
  Please consider mentioning note-worthy improvements made to the family recently. [code: description-not-updated]

⚠ WARN: Ensure fonts have ScriptLangTags declared on the 'meta' table.

• com.google.fonts/check/meta/script_lang_tags

--- 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]

[8] Rosario[wght].ttf

🔥 FAIL: Checks METADATA.pb font.post_script_name matches postscript name declared on the name table.

• com.google.fonts/check/metadata/nameid/post_script_name

• 🔥 FAIL Unmatched postscript name in font: TTF has "Rosario-Regular" while METADATA.pb has "Rosario-Light". [code: mismatch]

🔥 FAIL: METADATA.pb font.full_name value matches fullname declared on the name table?

• com.google.fonts/check/metadata/nameid/full_name

• 🔥 FAIL Unmatched fullname in font: TTF has "Rosario Regular" while METADATA.pb has "Rosario Light". [code: mismatch]

🔥 FAIL: METADATA.pb font.name and font.full_name fields match the values declared on the name table?

• com.google.fonts/check/metadata/nameid/family_and_full_names

• 🔥 FAIL METADATA.pb: Fullname "Rosario Light" does not match name table entry "Rosario Regular"! [code: fullname-mismatch]

⚠ WARN: Check copyright namerecords match license file.

• com.google.fonts/check/name/license

--- 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?

• com.google.fonts/check/name/license_url

--- 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?

• com.google.fonts/check/ligature_carets

--- 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?

• com.google.fonts/check/kerning_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
  • i + f
  • f + l
  • l + f
  • i + l

  [code: lacks-kern-info]

⚠ WARN: Ensure fonts have ScriptLangTags declared on the 'meta' table.

• com.google.fonts/check/meta/script_lang_tags

--- 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]

Summary

💔 ERROR	🔥 FAIL	⚠ WARN	💤 SKIP	ℹ INFO	🍞 PASS	🔎 DEBUG
0	6	12	93	19	280	0
0%	1%	3%	23%	5%	68%	0%

Note: The following loglevels were omitted in this report:

• SKIP
• INFO
• PASS
• DEBUG

[m4rc1e]

Lighter weights appear lighter. I guess this is intentional?

[thlinard]

Currently in API, Light = Regular. But now it appears as originally intended: https://github.com/Omnibus-Type/Rosario/blob/master/sources/Rosario-01.png

[aaronbell]

Yes, appears intentional.

[google-cla]

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 @googlebot I consent. in this pull request.

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 cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

[google-cla]

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 @googlebot I consent. in this pull request.

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 cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

[aaronbell]

@googlebot I consent.

[google-cla]

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 @googlebot I consent. in this pull request.

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 cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

[aaronbell]

@googlebot I consent.

[google-cla]

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 @googlebot I consent. in this pull request.

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 cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

[RosaWagner]

1733 files changed, I think there is an issue with this PR.

[aaronbell]

Resubmitting