Update AbeeZee #4227
Comments
RosaWagner
added
-- Needs Upstream Resolution
Fontbakery reportFontbakery version: 0.8.4 [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.
[11] ABeeZee-Italic.ttf💔 ERROR: Check for font-v versioning.--- Rationale --- The git sha1 tagging and dev/release features of Source Foundry `font-v` tool are awesome and we would love to consider upstreaming the approach into fontmake someday. For now we only emit a WARN if a given font does not yet follow the experimental versioning style, but at some point we may start enforcing it.
🔥 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 name table: FONT_FAMILY_NAME entries.--- Rationale --- Checks that the family name infered from the font filename matches the string at nameID 1 (NAMEID_FONT_FAMILY_NAME) if it conforms to RIBBI and otherwise checks that nameID 1 is the family name + the style name.
🔥 FAIL: Check name table: FULL_FONT_NAME entries.--- Rationale --- Requirements for the FULL_FONT_NAME entries in the 'name' table.
⚠ 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: 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 font contains no unreachable glyphs--- Rationale --- Glyphs are either accessible directly through Unicode codepoints or through substitution rules. Any glyphs not accessible by either of these means are redundant and serve only to increase the font's file size.
⚠ WARN: Check if each glyph has the recommended amount of contours.--- Rationale --- Visually QAing thousands of glyphs by hand is tiring. Most glyphs can only be constructured in a handful of ways. This means a glyph's contour count will only differ slightly amongst different fonts, e.g a 'g' could either be 2 or 3 contours, depending on whether its double story or single story. However, a quotedbl should have 2 contours, unless the font belongs to a display family. This check currently does not cover variable fonts because there's plenty of alternative ways of constructing glyphs with multiple outlines for each feature in a VarFont. The expected contour count data for this check is currently optimized for the typical construction of glyphs in static fonts.
The following glyphs do not have the recommended number of contours:
⚠ 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: Are any segments inordinately short?
--- Rationale --- This check looks for outline segments which seem particularly short (less than 0.6% of the overall path length). This check is not run for variable fonts, as they may legitimately have short segments. As this check is liable to generate significant numbers of false positives, it will pass if there are more than 100 reported short segments.
⚠ WARN: Do any segments have colinear vectors?
--- Rationale --- This check looks for consecutive line segments which have the same angle. This normally happens if an outline point has been added by accident. This check is not run for variable fonts, as they may legitimately have colinear vectors.
[11] ABeeZee-Regular.ttf💔 ERROR: Check for font-v versioning.--- Rationale --- The git sha1 tagging and dev/release features of Source Foundry `font-v` tool are awesome and we would love to consider upstreaming the approach into fontmake someday. For now we only emit a WARN if a given font does not yet follow the experimental versioning style, but at some point we may start enforcing it.
🔥 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 name table: FONT_FAMILY_NAME entries.--- Rationale --- Checks that the family name infered from the font filename matches the string at nameID 1 (NAMEID_FONT_FAMILY_NAME) if it conforms to RIBBI and otherwise checks that nameID 1 is the family name + the style name.
🔥 FAIL: Check name table: FULL_FONT_NAME entries.--- Rationale --- Requirements for the FULL_FONT_NAME entries in the 'name' table.
⚠ 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: 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 font contains no unreachable glyphs--- Rationale --- Glyphs are either accessible directly through Unicode codepoints or through substitution rules. Any glyphs not accessible by either of these means are redundant and serve only to increase the font's file size.
⚠ WARN: Check if each glyph has the recommended amount of contours.--- Rationale --- Visually QAing thousands of glyphs by hand is tiring. Most glyphs can only be constructured in a handful of ways. This means a glyph's contour count will only differ slightly amongst different fonts, e.g a 'g' could either be 2 or 3 contours, depending on whether its double story or single story. However, a quotedbl should have 2 contours, unless the font belongs to a display family. This check currently does not cover variable fonts because there's plenty of alternative ways of constructing glyphs with multiple outlines for each feature in a VarFont. The expected contour count data for this check is currently optimized for the typical construction of glyphs in static fonts.
The following glyphs do not have the recommended number of contours:
⚠ 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: Are any segments inordinately short?
--- Rationale --- This check looks for outline segments which seem particularly short (less than 0.6% of the overall path length). This check is not run for variable fonts, as they may legitimately have short segments. As this check is liable to generate significant numbers of false positives, it will pass if there are more than 100 reported short segments.
⚠ WARN: Do any segments have colinear vectors?
--- Rationale --- This check looks for consecutive line segments which have the same angle. This normally happens if an outline point has been added by accident. This check is not run for variable fonts, as they may legitimately have colinear vectors.
Summary
Note: The following loglevels were omitted in this report:
BEFORE / AFTER
|
|
@emmamarichal tu peux ajouter/dessiner les caractères manquants (sauf divisionslash, deprecated), et je vais ajouter le nom de famille à Fontbakery. Il faudrait aussi renommer les .cap en .case et mettre à jour les features ;) |
This comment has been minimized.
This comment has been minimized.
|
The update of fontbakery brought a lot of normally non required missing glyphs. Fontbakery reportFontbakery version: 0.8.6 [11] ABeeZee-Italic.ttf💔 ERROR: Check for font-v versioning.--- Rationale --- The git sha1 tagging and dev/release features of Source Foundry `font-v` tool are awesome and we would love to consider upstreaming the approach into fontmake someday. For now we only emit a WARN if a given font does not yet follow the experimental versioning style, but at some point we may start enforcing it.
🔥 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 name table: FONT_FAMILY_NAME entries.--- Rationale --- Checks that the family name infered from the font filename matches the string at nameID 1 (NAMEID_FONT_FAMILY_NAME) if it conforms to RIBBI and otherwise checks that nameID 1 is the family name + the style name.
🔥 FAIL: Check name table: FULL_FONT_NAME entries.--- Rationale --- Requirements for the FULL_FONT_NAME entries in the 'name' table.
⚠ 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: 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 font contains no unreachable glyphs--- Rationale --- Glyphs are either accessible directly through Unicode codepoints or through substitution rules. Any glyphs not accessible by either of these means are redundant and serve only to increase the font's file size.
⚠ WARN: Check if each glyph has the recommended amount of contours.--- Rationale --- Visually QAing thousands of glyphs by hand is tiring. Most glyphs can only be constructured in a handful of ways. This means a glyph's contour count will only differ slightly amongst different fonts, e.g a 'g' could either be 2 or 3 contours, depending on whether its double story or single story. However, a quotedbl should have 2 contours, unless the font belongs to a display family. This check currently does not cover variable fonts because there's plenty of alternative ways of constructing glyphs with multiple outlines for each feature in a VarFont. The expected contour count data for this check is currently optimized for the typical construction of glyphs in static fonts.
The following glyphs do not have the recommended number of contours: [code: contour-count] ⚠ 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.
Use -F or --full-lists to disable shortening of long lists. [code: found-misalignments] ⚠ WARN: Are any segments inordinately short?
--- Rationale --- This check looks for outline segments which seem particularly short (less than 0.6% of the overall path length). This check is not run for variable fonts, as they may legitimately have short segments. As this check is liable to generate significant numbers of false positives, it will pass if there are more than 100 reported short segments.
Use -F or --full-lists to disable shortening of long lists. [code: found-short-segments] ⚠ WARN: Do any segments have colinear vectors?
--- Rationale --- This check looks for consecutive line segments which have the same angle. This normally happens if an outline point has been added by accident. This check is not run for variable fonts, as they may legitimately have colinear vectors.
[11] ABeeZee-Regular.ttf💔 ERROR: Check for font-v versioning.--- Rationale --- The git sha1 tagging and dev/release features of Source Foundry `font-v` tool are awesome and we would love to consider upstreaming the approach into fontmake someday. For now we only emit a WARN if a given font does not yet follow the experimental versioning style, but at some point we may start enforcing it.
🔥 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 name table: FONT_FAMILY_NAME entries.--- Rationale --- Checks that the family name infered from the font filename matches the string at nameID 1 (NAMEID_FONT_FAMILY_NAME) if it conforms to RIBBI and otherwise checks that nameID 1 is the family name + the style name.
🔥 FAIL: Check name table: FULL_FONT_NAME entries.--- Rationale --- Requirements for the FULL_FONT_NAME entries in the 'name' table.
⚠ 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: 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 font contains no unreachable glyphs--- Rationale --- Glyphs are either accessible directly through Unicode codepoints or through substitution rules. Any glyphs not accessible by either of these means are redundant and serve only to increase the font's file size.
⚠ WARN: Check if each glyph has the recommended amount of contours.--- Rationale --- Visually QAing thousands of glyphs by hand is tiring. Most glyphs can only be constructured in a handful of ways. This means a glyph's contour count will only differ slightly amongst different fonts, e.g a 'g' could either be 2 or 3 contours, depending on whether its double story or single story. However, a quotedbl should have 2 contours, unless the font belongs to a display family. This check currently does not cover variable fonts because there's plenty of alternative ways of constructing glyphs with multiple outlines for each feature in a VarFont. The expected contour count data for this check is currently optimized for the typical construction of glyphs in static fonts.
The following glyphs do not have the recommended number of contours: [code: contour-count] ⚠ 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.
Use -F or --full-lists to disable shortening of long lists. [code: found-misalignments] ⚠ WARN: Are any segments inordinately short?
--- Rationale --- This check looks for outline segments which seem particularly short (less than 0.6% of the overall path length). This check is not run for variable fonts, as they may legitimately have short segments. As this check is liable to generate significant numbers of false positives, it will pass if there are more than 100 reported short segments.
⚠ WARN: Do any segments have colinear vectors?
--- Rationale --- This check looks for consecutive line segments which have the same angle. This normally happens if an outline point has been added by accident. This check is not run for variable fonts, as they may legitimately have colinear vectors.
Summary
Note: The following loglevels were omitted in this report:
|
|
I opened an issue to see with Felipe if the glyphs coverage is a mistake or… Also, I added ABeeZee to the camelcase allow-list in that PR, so I don't know why there is still the fail. I'll check the font source before opening an issue. |
RosaWagner
removed
the
-- Needs Upstream Resolution
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
upstream: https://github.com/googlefonts/abeezee
AbeeZee is the first family dir in this repo and referenced multiple times in our documentation. People probably go there first to have an example of family directories. It would better then if it matches the spec (which is not the case right now in term of copyright string etc.)
Would also like to approve the removal of the RFN --> @davelab6
Production notes
The text was updated successfully, but these errors were encountered: