Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Fontbakery results #9

Closed
vv-monsalve opened this issue Apr 28, 2023 · 1 comment
Closed

Fontbakery results #9

vv-monsalve opened this issue Apr 28, 2023 · 1 comment

Comments

@vv-monsalve
Copy link
Contributor

This is the current report after the first production fixes were performed. Please merge the PR that includes those changes before addressing the Fails and Warns. All of them are related to what was previously informed in #8 that is yet pending to be solved.

Fontbakery report

Fontbakery version: 0.8.11

[13] NationalPark[wght].ttf
💔 ERROR: Familyname must be unique according to namecheck.fontdata.com (com.google.fonts/check/fontdata_namecheck)

We need to check names are not already used, and today the best place to check that is http://namecheck.fontdata.com

  • 💔 ERROR Failed to access: http://namecheck.fontdata.com.
    This check relies on the external service http://namecheck.fontdata.com via the internet. While the service cannot be reached or does not respond this check is broken.

      You can exclude this check with the command line option:
      -x com.google.fonts/check/fontdata_namecheck
    
      Or you can wait until the service is available again.
      If the problem persists please report this issue at: https://github.com/googlefonts/fontbakery/issues
    
      Original error message:
      <class 'requests.exceptions.ConnectionError'> [code: namecheck-service]
    
🔥 FAIL: Check Google Fonts glyph coverage. (com.google.fonts/check/glyph_coverage)

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 Missing required codepoints:

    • 0x0141 (LATIN CAPITAL LETTER L WITH STROKE)

    • 0x00D8 (LATIN CAPITAL LETTER O WITH STROKE)

    • 0x0142 (LATIN SMALL LETTER L WITH STROKE)

    • 0x00F8 (LATIN SMALL LETTER O WITH STROKE)

    • 0x0024 (DOLLAR SIGN)

    • 0x00A5 (YEN SIGN)
      [code: missing-codepoints]

🔥 FAIL: Check font follows the Google Fonts vertical metric schema (com.google.fonts/check/vertical_metrics)

This check generally enforces Google Fonts’ vertical metrics specifications. In particular: * lineGap must be 0 * Sum of hhea ascender + abs(descender) + linegap must be between 120% and 200% of UPM * Warning if sum is over 150% of UPM

The threshold levels 150% (WARN) and 200% (FAIL) are somewhat arbitrarily chosen and may hint at a glaring mistake in the metrics calculations or UPM settings.

Our documentation includes further information: https://github.com/googlefonts/gf-docs/tree/main/VerticalMetrics

  • 🔥 FAIL The sum of hhea.ascender + abs(hhea.descender) + hhea.lineGap is 1180 when it should be at least 1200 [code: bad-hhea-range]
🔥 FAIL: Ensure soft_dotted characters lose their dot when combined with marks that replace the dot. (com.google.fonts/check/soft_dotted)

An accent placed on characters with a "soft dot", like i or j, causes the dot to disappear. An explicit dot above can be added where required. See "Diacritics on i and j" in Section 7.1, "Latin" in The Unicode Standard.

Characters with the Soft_Dotted property are listed in https://www.unicode.org/Public/UCD/latest/ucd/PropList.txt

  • 🔥 FAIL The dot of soft dotted characters used in orthographies must disappear in the following strings: į̀ į́ į̂ į̃ į̄ į̌ ị̀ ị́ ị̂ ị̃ ị̄

The dot of soft dotted characters should disappear in other cases, for example: i̦̇ i̦̊ i̦̋ ǐ̦ i̦̒ j̦̀ j̦́ j̦̃ j̦̄ j̦̆ j̦̇ j̦̈ j̦̉ j̦̊ j̦̋ ǰ̦ j̦̏ j̦̑ j̦̒ į̆ [code: soft-dotted]

WARN: Checking OS/2 achVendID. (com.google.fonts/check/vendor_id)

Microsoft keeps a list of font vendors and their respective contact info. This list is updated regularly and is indexed by a 4-char "Vendor ID" which is stored in the achVendID field of the OS/2 table.

Registering your ID is not mandatory, but it is a good practice since some applications may display the type designer / type foundry contact info on some dialog and also because that info will be visible on Microsoft's website:

https://docs.microsoft.com/en-us/typography/vendors/

This check verifies whether or not a given font's vendor ID is registered in that list or if it has some of the default values used by the most common font editors.

Each new FontBakery release includes a cached copy of that list of vendor IDs. If you registered recently, you're safe to ignore warnings emitted by this check, since your ID will soon be included in one of our upcoming releases.

  • WARN OS/2 VendorID value 'NONE' is not yet recognized. If you registered it recently, then it's safe to ignore this warning message. Otherwise, you should set it to your own unique 4 character code, and register it with Microsoft at https://www.microsoft.com/typography/links/vendorlist.aspx
    [code: unknown]
WARN: Are there caret positions declared for every ligature? (com.google.fonts/check/ligature_carets)

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 positioning values for these ligature glyphs:

    • fl

    [code: incomplete-caret-pos-data]

WARN: Is there kerning info for non-ligated sequences? (com.google.fonts/check/kerning_for_non_ligated_sequences)

Fonts with ligatures should have kerning on the corresponding non-ligated sequences for text where ligatures aren't used (eg impallari/Raleway#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 variable fonts include an avar table. (com.google.fonts/check/mandatory_avar_table)

Most variable fonts should include an avar table to correctly define axes progression rates.

For example, a weight axis from 0% to 100% doesn't map directly to 100 to 1000, because a 10% progression from 0% may be too much to define the 200, while 90% may be too little to define the 900.

If the progression rates of axes is linear, this check can be ignored. Fontmake will also skip adding an avar table if the progression rates are linear. However, we still recommend designers visually proof each instance is at the expected weight, width etc.

  • WARN This variable font does not have an avar table. [code: missing-avar]
WARN: Ensure fonts have ScriptLangTags declared on the 'meta' table. (com.google.fonts/check/meta/script_lang_tags)

The OpenType 'meta' table originated at Apple. Microsoft added it to OT with just two DataMap records:

  • dlng: comma-separated ScriptLangTags that indicate which scripts, or languages and scripts, with possible variants, the font is designed for.

  • slng: comma-separated ScriptLangTags that indicate which scripts, or languages and scripts, with possible variants, the font supports.

The slng structure is intended to describe which languages and scripts the font overall supports. For example, a Traditional Chinese font that also contains Latin characters, can indicate Hant,Latn, showing that it supports Hant, the Traditional Chinese variant of the Hani script, and it also supports the Latn script.

The dlng structure is far more interesting. A font may contain various glyphs, but only a particular subset of the glyphs may be truly "leading" in the design, while other glyphs may have been included for technical reasons. Such a Traditional Chinese font could only list Hant there, showing that it’s designed for Traditional Chinese, but the font would omit Latn, because the developers don’t think the font is really recommended for purely Latin-script use.

The tags used in the structures can comprise just script, or also language and script. For example, if a font has Bulgarian Cyrillic alternates in the locl feature for the cyrl BGR OT languagesystem, it could also indicate in dlng explicitly that it supports bul-Cyrl. (Note that the scripts and languages in meta use the ISO language and script codes, not the OpenType ones).

This check ensures that the font has the meta table containing the slng and dlng structures.

All families in the Google Fonts collection should contain the 'meta' table. Windows 10 already uses it when deciding on which fonts to fall back to. The Google Fonts API and also other environments could use the data for smarter filtering. Most importantly, those entries should be added to the Noto fonts.

In the font making process, some environments store this data in external files already. But the meta table provides a convenient way to store this inside the font file, so some tools may add the data, and unrelated tools may read this data. This makes the solution much more portable and universal.

  • WARN This font file does not have a 'meta' table. [code: lacks-meta-table]
WARN: Glyph names are all valid? (com.google.fonts/check/valid_glyphnames)

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 The following glyph names may be too long for some legacy systems which may expect a maximum 31-char length limit:
    acircumflex.loclVIT.BRACKET.varAlt01 [code: legacy-long-names]
WARN: Check font contains no unreachable glyphs (com.google.fonts/check/unreachable_glyphs)

Glyphs are either accessible directly through Unicode codepoints or through substitution rules.

In Color Fonts, glyphs are also referenced by the COLR table.

Any glyphs not accessible by either of these means are redundant and serve only to increase the font's file size.

  • WARN The following glyphs could not be reached by codepoint or substitution rules:

    • C.001

    • E.001

    • F.001

    • IJ.001

    • a.BRACKET.varAlt01

    • aacute.BRACKET.varAlt01

    • aacute.loclVIT.BRACKET.varAlt01

    • abreve.BRACKET.varAlt01

    • abreve.loclVIT.BRACKET.varAlt01

    • acircumflex.BRACKET.varAlt01

    • 37 more.

Use -F or --full-lists to disable shortening of long lists.
[code: unreachable-glyphs]

WARN: Does the font contain a soft hyphen? (com.google.fonts/check/soft_hyphen)

The 'Soft Hyphen' character (codepoint 0x00AD) is used to mark a hyphenation possibility within a word in the absence of or overriding dictionary hyphenation.

It is supposed to be zero-width and invisible.

It is also mostly an obsolete mechanism now, and the character is typicaly only included in fonts for legacy codepage coverage.

  • WARN This font has a 'Soft Hyphen' character. [code: softhyphen]
WARN: Check math signs have the same width. (com.google.fonts/check/math_signs_width)

It is a common practice to have math signs sharing the same width (preferably the same width as tabular figures accross the entire font family).

This probably comes from the will to avoid additional tabular math signs knowing that their design can easily share the same width.

  • WARN The most common width is 536 among a set of 2 math glyphs.
    The following math glyphs have a different width, though:

Width = 545:
less, greater

Width = 554:
equal

Width = 540:
logicalnot

Width = 539:
plusminus

Width = 504:
multiply

Width = 552:
minus

Width = 550:
approxequal

Width = 569:
notequal

Width = 537:
greaterequal, lessequal
[code: width-outliers]


Summary

💔 ERROR 🔥 FAIL ⚠ WARN 💤 SKIP ℹ INFO 🍞 PASS 🔎 DEBUG
1 3 9 97 8 124 0
0% 1% 4% 40% 3% 51% 0%

Note: The following loglevels were omitted in this report:

  • SKIP
  • INFO
  • PASS
  • DEBUG
@vv-monsalve
Copy link
Contributor Author

Closing this here as further Fails and Warns will be reported individually

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant