cairo: v3.116 added #2380
Merged
cairo: v3.116 added #2380
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.7.20 [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/master/prebuilt/workarounds/ftxvalidator/ssh-implementation/ftxvalidator
[6] Cairo[wght].ttf🔥 FAIL: 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 must 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.
🔥 FAIL: 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
A glyph name may be up to 31 characters in length, must be entirely comprised of characters from the following set: A-Z a-z 0-9 .(period) (underscore). and must not start with a digit or period. There are a few exceptions such as the special character ".notdef". The glyph names "twocents", "a1", and "" are all valid, while "2cents" and ".twocents" are not. [code: found-invalid-names] ⚠ 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: Font has old ttfautohint applied?--- Rationale --- This check finds which version of ttfautohint was used, by inspecting name table entries and then finds which version of ttfautohint is currently installed in the system.
⚠ WARN: METADATA.pb: Fontfamily is listed on Google Fonts API?
⚠ WARN: 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 value 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. Another acceptable value is 2000. Since TT outlines are all integers (no floats), then instances in a VF suffer rounding compromises, and therefore a 1000 UPM is to small because it forces too many such compromises. Therefore 2000 is a good 'new VF standard', because 2000 is a simple 2x conversion from existing fonts drawn on a 1000 UPM, and anyone who knows what 10 units can do for 1000 UPM will know what 20 units does too. Additionally, values above 2048 would result in filesize increases with not much added benefit.
Summary
Note: The following loglevels were omitted in this report:
Diff images: qa.zip |
|
Metadata is good. Here's some issues I just found
Hinting still causing issues for fractions
We should release the family unhinted and fix the brackets. Please inspect the diff images to if there's anything else wrong. Parenthesis also has same issue |
|
I talked with @Gue3bara about this yesterday and told him I would cc him on this pull request so we can work together in this thread to figure out the best way forward for this typeface. There have been lots of improvements to Cairo since it has last been updated. The most notable would be that the Black weight has more color. See the example screenshot from FontGoggles below: I think this is an improvement, the Black weight looks much more like a Black in the latest upstream version. @Gue3bara agrees and has also suggested adding a new weight between the bold and the black. Maybe we should just update it to go from 100-900 hitting each weight? What I did for now is to move the middle master to Regular, then try to keep all the weights as consistent as possible with the weights of the current static fonts. Then when I hit 700 the color ramps up shapely to the Black weight at 900, which wont match the current static font black well. If Marc thinks the regressions are too much, I can easily update the PR with new weights that match across the whole range. |
|
Thank you @eliheuer for all the continuous help, For now, I agree with Eli's proposal on the masters moving and i will be working on further testing and development to hopefully be able to publish this updated version very soon on the platform as it will have a lot of needed improvements. |
Fontbakery reportFontbakery version: 0.7.21 [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/master/prebuilt/workarounds/ftxvalidator/ssh-implementation/ftxvalidator
[5] Cairo[wght].ttf🔥 FAIL: 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 must 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.
🔥 FAIL: 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
A glyph name may be up to 31 characters in length, must be entirely comprised of characters from the following set: A-Z a-z 0-9 .(period) (underscore). and must not start with a digit or period. There are a few exceptions such as the special character ".notdef". The glyph names "twocents", "a1", and "" are all valid, while "2cents" and ".twocents" are not. [code: found-invalid-names] ⚠ 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: METADATA.pb: Fontfamily is listed on Google Fonts API?
⚠ WARN: 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 value 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. Another acceptable value is 2000. Since TT outlines are all integers (no floats), then instances in a VF suffer rounding compromises, and therefore a 1000 UPM is to small because it forces too many such compromises. Therefore 2000 is a good 'new VF standard', because 2000 is a simple 2x conversion from existing fonts drawn on a 1000 UPM, and anyone who knows what 10 units can do for 1000 UPM will know what 20 units does too. Additionally, values above 2048 would result in filesize increases with not much added benefit.
Summary
Note: The following loglevels were omitted in this report:
Diff images: qa.zip |
|
My changes were merged into the upstream master. The above Fontbakery report and QA images are from a force push... They are unhinted, and I attempted fixing the brace and bracket issues as Marc requested. |
|
Thanks. This is a big improvement. "quotesinglbase" is missing outlines. Please readd them. I think we're good after this. Please also look into the diff images yourself, I may have missed some issues. @Gue3bara could you also look at the latest gf-bot report? |
Closed
|
@m4rc1e I am checking the gf-bot report and running further tests and small modifications that will improve it, even further, I will be working in it today all day so by the end of the day I expect to report back to you |
|
If the new 900 is going to cause regressions and make user documents bolder, perhaps it should be setup as a 1000 weight? |
This was referenced Mar 11, 2020
Fontbakery reportFontbakery version: 0.7.21 [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/master/prebuilt/workarounds/ftxvalidator/ssh-implementation/ftxvalidator
[5] Cairo[wght].ttf🔥 FAIL: 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 must 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.
🔥 FAIL: 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
A glyph name may be up to 31 characters in length, must be entirely comprised of characters from the following set: A-Z a-z 0-9 .(period) (underscore). and must not start with a digit or period. There are a few exceptions such as the special character ".notdef". The glyph names "twocents", "a1", and "" are all valid, while "2cents" and ".twocents" are not. [code: found-invalid-names] ⚠ 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: METADATA.pb: Fontfamily is listed on Google Fonts API?
⚠ WARN: 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 value 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. Another acceptable value is 2000. Since TT outlines are all integers (no floats), then instances in a VF suffer rounding compromises, and therefore a 1000 UPM is to small because it forces too many such compromises. Therefore 2000 is a good 'new VF standard', because 2000 is a simple 2x conversion from existing fonts drawn on a 1000 UPM, and anyone who knows what 10 units can do for 1000 UPM will know what 20 units does too. Additionally, values above 2048 would result in filesize increases with not much added benefit.
Summary
Note: The following loglevels were omitted in this report:
Diff images: qa.zip |
|
The above force pushed update is from the upstream repo: https://github.com/Gue3bara/Cairo @Gue3bara Worked on the Glyphs source some, and I wanted updated QA images to work from, so I force pushed this commit. No need for a review from Marc at this point, looking at the source file I still see some issues that need to be fixed. |
|
I solved the issues @eliheuer reported and ruan some further testing looking at the diff images -very handy- |
|
Thanks both of you for reviewing the diffs and making amendments. Ping me when you're done and I'll take a final look. |
Fontbakery reportFontbakery version: 0.7.21 [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/master/prebuilt/workarounds/ftxvalidator/ssh-implementation/ftxvalidator
[5] Cairo[wght].ttf🔥 FAIL: 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 must 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.
🔥 FAIL: 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
A glyph name may be up to 31 characters in length, must be entirely comprised of characters from the following set: A-Z a-z 0-9 .(period) (underscore). and must not start with a digit or period. There are a few exceptions such as the special character ".notdef". The glyph names "twocents", "a1", and "" are all valid, while "2cents" and ".twocents" are not. [code: found-invalid-names] ⚠ 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: METADATA.pb: Fontfamily is listed on Google Fonts API?
⚠ WARN: 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 value 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. Another acceptable value is 2000. Since TT outlines are all integers (no floats), then instances in a VF suffer rounding compromises, and therefore a 1000 UPM is to small because it forces too many such compromises. Therefore 2000 is a good 'new VF standard', because 2000 is a simple 2x conversion from existing fonts drawn on a 1000 UPM, and anyone who knows what 10 units can do for 1000 UPM will know what 20 units does too. Additionally, values above 2048 would result in filesize increases with not much added benefit.
Summary
Note: The following loglevels were omitted in this report:
Diff images: qa.zip |
|
The above force pushed update is from the upstream repo: https://github.com/Gue3bara/Cairo I'm reviewing the new QA images and will report any issues I find to the upstream issue tracker, and list them below. The remaining issues are:
|
Fontbakery reportFontbakery version: 0.7.21 [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/master/prebuilt/workarounds/ftxvalidator/ssh-implementation/ftxvalidator
[5] Cairo[wght].ttf🔥 FAIL: 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 must 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.
🔥 FAIL: 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
A glyph name may be up to 31 characters in length, must be entirely comprised of characters from the following set: A-Z a-z 0-9 .(period) (underscore). and must not start with a digit or period. There are a few exceptions such as the special character ".notdef". The glyph names "twocents", "a1", and "" are all valid, while "2cents" and ".twocents" are not. [code: found-invalid-names] ⚠ 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: METADATA.pb: Fontfamily is listed on Google Fonts API?
⚠ WARN: 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 value 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. Another acceptable value is 2000. Since TT outlines are all integers (no floats), then instances in a VF suffer rounding compromises, and therefore a 1000 UPM is to small because it forces too many such compromises. Therefore 2000 is a good 'new VF standard', because 2000 is a simple 2x conversion from existing fonts drawn on a 1000 UPM, and anyone who knows what 10 units can do for 1000 UPM will know what 20 units does too. Additionally, values above 2048 would result in filesize increases with not much added benefit.
Summary
Note: The following loglevels were omitted in this report:
Diff images: qa.zip |
|
The above force pushed update is from the upstream repo: https://github.com/Gue3bara/Cairo |
|
@eliheuer I will do one last check around and fix the outer overlap you mentioned on the eastern number 7 and 8 |
|
Thanks! We still need to figure out the shift in weight issues that @davelab6 brought up here. The problem is that when a font is updated and the weight/metrics change significantly, it can shift the layout and cause aesthetic changes on websites that are using the font served from Google Fonts. There have been issues like this in the past where people have been very upset. I believe there is one incident in particular that is known as "Montserrat-gate" where this caused lots of trouble, so Dave and Marc want to avoid changes in weight and metrics as much as possible. It's a tricky situation because your upstream is clearly an improvement over what is currently available, and the black weight in the old version doesn't really match what I would consider a black, it's more of a Bold/ExtraBold. Also, there are people who I assume use this font already in its current form(I think I remember @Gue3bara posted a screenshot of a TV news program using it!). When I made the pull request to @Gue3bara's upstream repo with a new Glyphs file, I tried to do my best to make a compromise that would make everyone happy, but Marc or Dave need to give a firm yes or no if this amount of weight change is acceptable or not. |
|
Thank you @eliheuer for clarifying the point, which is very important to consider, Cairo is currently the most used Arabic font on the platform -149mil views a week- and used offline very widely -i never expected this insane spread-
What i propose is to make the new black Heavy 1000 and interpolate a new black 900 that matches the old one in metrics |
|
That sounds good, thanks! Like I said above, ideally we can find a compromise that works for everyone and doesn't negatively effect the design of the upstream typeface. |
|
The font looks really improve. Although, missing instances in FVAR table, + an ExtraBlack that is not supported by google. I suggest to move current Black to ExtraBold, and ExtraBlack to Black. + adding a Medium at 500. --> I think regression of weight on extreme weight styles is okay since less used than intermediate ones, and even less in an entire paragraph (consequences are low). Now @aaronbell is overly trained to handle these issues:
|
|
@RosaWagner According to https://github.com/googlefonts/gf-docs/tree/main/Spec#axis-particles, ExtraBlack is supported. Is this a mismatch? Not sure what happened with that undefined one. I've run gen-stat to fix it up. |
Fontbakery reportFontbakery version: 0.8.2 [10] Cairo[wght].ttf🔥 FAIL: Ensure component transforms do not perform scaling or rotation.--- Rationale --- Some families have glyphs which have been constructed by using transformed components e.g the 'u' being constructed from a flipped 'n'. From a designers point of view, this sounds like a win (less work). However, such approaches can lead to rasterization issues, such as having the 'u' not sitting on the baseline at certain sizes after running the font through ttfautohint. As of July 2019, Marc Foley observed that ttfautohint assigns cvt values to transformed glyphs as if they are not transformed and the result is they render very badly, and that vttLib does not support flipped components. When building the font with fontmake, this problem can be fixed by using the "Decompose Transformed Components" filter.
🔥 FAIL: Check glyphs do not have components which are themselves components.--- Rationale --- There have been bugs rendering variable fonts with nested components. Additionally, some static fonts with nested components have been reported to have rendering and printing issues. For more info, see: * https://github.com/googlefonts/fontbakery/issues/2961 * https://github.com/arrowtype/recursive/issues/412
🔥 FAIL: Validate STAT particle names and values match the fallback names in GFAxisRegistry.--- Rationale --- Check that particle names and values on STAT table match the fallback names in each axis entry at the Google Fonts Axis Registry, available at https://github.com/google/fonts/tree/main/axisregistry
⚠ 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: 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: 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: 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
Summary
Note: The following loglevels were omitted in this report:
|
|
There is a ExtraBold (800) instance in Again, as with Literata, there is only a real issue when an |
I stand corrected ! So I don't remember where I read/heard that, I'll ask for confirmation to be sure, but I don't see the issue in having it in the STAT, but I don't think it be generated generated in the ZIP by the API since it is not in the axis registry. |
|
@aaronbell I looked at the building script which I didn't understand so well, but you could take care of the nested and transformed components issues in there by adding argument to the fontmake command: |
|
@RosaWagner Yeah, fontbakery issues a FAIL if you have ExtraBlack at 1000, but according to gf-spec it is allowed. Kind of confusing :). Anyway, I rebuilt the font using the UFR set up from the upstream repro (stripping out the slnt bits) and uploaded. Should be GTG now. |
Fontbakery reportFontbakery version: 0.8.2 [8] Cairo[wght].ttf🔥 FAIL: Validate STAT particle names and values match the fallback names in GFAxisRegistry.--- Rationale --- Check that particle names and values on STAT table match the fallback names in each axis entry at the Google Fonts Axis Registry, available at https://github.com/google/fonts/tree/main/axisregistry
⚠ 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: 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: 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: 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
Summary
Note: The following loglevels were omitted in this report:
|
|
LGTM. Since it's a pretty popular font and there is a slight horizontal regression, I wait for Marc's confirmation too. |
From the upstream repo: https://github.com/Gue3bara/Cairo At commit: 886eed8
Adding a proper STAT table to the font. Also solving the metadata per request from Rosalie.
Updated using the UFR build script
Fontbakery reportFontbakery version: 0.8.2 [8] Cairo[wght].ttf🔥 FAIL: Validate STAT particle names and values match the fallback names in GFAxisRegistry.--- Rationale --- Check that particle names and values on STAT table match the fallback names in each axis entry at the Google Fonts Axis Registry, available at https://github.com/google/fonts/tree/main/axisregistry
⚠ 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: 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: 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: 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
Summary
Note: The following loglevels were omitted in this report:
|
|
LGTM. Thanks for this and apologies for the delay. |
RosaWagner
added
--- to_sandbox
and removed
-- Needs confirmation
RosaWagner
added
--- to_production
III VF Replacement
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.
🚧 EDIT 🚧 latest force push is:
Taken from the upstream repo: https://github.com/Gue3bara/Cairo
At commit: Gue3bara/Cairo@8cecfd4