Post full FontBakery QA

This is what Fontbakery has to say, please ignore the ERROR, we are working on it. Most of it is about vertical metrics, it's normal since I didn't set them yet.

You can find at the end of the report some images to download in order to check out the rendering:

Fontbakery report

Fontbakery version: 0.7.33

[11] Brygada1918[wght].ttf

💔 ERROR: Validate METADATA.pb axes values are within gf-axisregistry bounds.

* [com.google.fonts/check/metadata/gf-axisregistry_bounds](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/metadata/gf-axisregistry_bounds)

--- Rationale ---

Each axis range in a METADATA.pb file must be registered, and within the bounds
of the axis definition in the Google Fonts Axis Registry, available at
https://github.com/google/fonts/tree/master/axisregistry

* 💔 **ERROR** Failed with AttributeError: 'NoneType' object has no attribute 'axes'

💔 ERROR: Validate METADATA.pb axes tags are defined in gf-axisregistry.

* [com.google.fonts/check/metadata/gf-axisregistry_valid_tags](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/metadata/gf-axisregistry_valid_tags)

--- Rationale ---

Ensure all axes in a METADATA.pb file are registered in the Google Fonts Axis
Registry, available at https://github.com/google/fonts/tree/master/axisregistry

Why does Google Fonts have its own Axis Registry?

We support a superset of the OpenType axis registry axis set, and use
additional metadata for each axis. Axes present in a font file but not in this
registry will not function via our API. No variable font is expected to support
all of the axes here.

Any font foundry or distributor library that offers variable fonts has a
implicit, latent, de-facto axis registry, which can be extracted by scanning
the library for axes' tags, labels, and min/def/max values. While in 2016
Microsoft originally offered to include more axes in the OpenType 1.8
specification (github.com/microsoft/OpenTypeDesignVariationAxisTags), as of
August 2020, this effort has stalled. We hope more foundries and distributors
will publish documents like this that make their axes explicit, to encourage of
adoption of variable fonts throughout the industry, and provide source material
for a future update to the OpenType specification's axis registry.

* 💔 **ERROR** Failed with AttributeError: 'NoneType' object has no attribute 'axes'

💔 ERROR: Validate VF axes match the ones declared on METADATA.pb.

* [com.google.fonts/check/metadata/consistent_axis_enumeration](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/metadata/consistent_axis_enumeration)

--- Rationale ---

All font variation axes present in the font files must be properly declared on
METADATA.pb so that they can be served by the GFonts API.

* 💔 **ERROR** Failed with AttributeError: 'NoneType' object has no attribute 'axes'

🔥 FAIL: Checking OS/2 usWinAscent & usWinDescent.

* [com.google.fonts/check/family/win_ascent_and_descent](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/universal.html#com.google.fonts/check/family/win_ascent_and_descent)

--- Rationale ---

A font's winAscent and winDescent values should be greater than the head
table's yMax, abs(yMin) values. If they are less than these values, clipping
can occur on Windows platforms
(https://github.com/RedHatBrand/Overpass/issues/33).

If the font includes tall/deep writing systems such as Arabic or Devanagari,
the winAscent and winDescent can be greater than the yMax and abs(yMin) to
accommodate vowel marks.

When the win Metrics are significantly greater than the upm, the linespacing
can appear too loose. To counteract this, enabling the OS/2 fsSelection bit 7
(Use_Typo_Metrics), will force Windows to use the OS/2 typo values instead.
This means the font developer can control the linespacing with the typo values,
whilst avoiding clipping by setting the win values to values greater than the
yMax and abs(yMin).

* 🔥 **FAIL** OS/2.usWinAscent value should be equal or greater than 1049, but got 950 instead [code: ascent] * 🔥 **FAIL** OS/2.usWinDescent value should be equal or greater than 436, but got 250 instead. [code: descent]

🔥 FAIL: Checking OS/2 Metrics match hhea Metrics.

* [com.google.fonts/check/os2_metrics_match_hhea](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/universal.html#com.google.fonts/check/os2_metrics_match_hhea)

--- Rationale ---

When OS/2 and hhea vertical metrics match, the same linespacing results on
macOS, GNU+Linux and Windows. Unfortunately as of 2018, Google Fonts has
released many fonts with vertical metrics that don't match in this way. When we
fix this issue in these existing families, we will create a visible change in
line/paragraph layout for either Windows or macOS users, which will upset some
of them.

But we have a duty to fix broken stuff, and inconsistent paragraph layout is
unacceptably broken when it is possible to avoid it.

If users complain and prefer the old broken version, they have the freedom to
take care of their own situation.

* 🔥 **FAIL** OS/2 sTypoAscender (750) and hhea ascent (950) must be equal. [code: ascender]

⚠ WARN: Checking OS/2 achVendID.

* [com.google.fonts/check/vendor_id](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/vendor_id)

--- Rationale ---

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

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

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

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

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

* ⚠ **WARN** OS/2 VendorID value '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: Check copyright namerecords match license file.

* [com.google.fonts/check/name/license](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/name/license)

--- Rationale ---

A known licensing description must be provided in the NameID 14 (LICENSE
DESCRIPTION) entries of the name table.

The source of truth for this check (to determine which license is in use) is a
file placed side-by-side to your font project including the licensing terms.

Depending on the chosen license, one of the following string snippets is
expected to be found on the NameID 13 (LICENSE DESCRIPTION) entries of the name
table:
- "This Font Software is licensed under the SIL Open Font License, Version 1.1.
This license is available with a FAQ at: https://scripts.sil.org/OFL"
- "Licensed under the Apache License, Version 2.0"
- "Licensed under the Ubuntu Font Licence 1.0."

Currently accepted licenses are Apache or Open Font License.
For a small set of legacy families the Ubuntu Font License may be acceptable as
well.

When in doubt, please choose OFL for new font projects.

* ⚠ **WARN** Please consider using HTTPS URLs at name table entry [plat=3, enc=1, name=13] [code: http-in-description] * ⚠ **WARN** For now we're still accepting http URLs, but you should consider using https instead. [code: http]

⚠ WARN: License URL matches License text on name table?

* [com.google.fonts/check/name/license_url](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/name/license_url)

--- Rationale ---

A known license URL must be provided in the NameID 14 (LICENSE INFO URL) entry
of the name table.

The source of truth for this check is the licensing text found on the NameID 13
entry (LICENSE DESCRIPTION).

The string snippets used for detecting licensing terms are:
- "This Font Software is licensed under the SIL Open Font License, Version 1.1.
This license is available with a FAQ at: https://scripts.sil.org/OFL"
- "Licensed under the Apache License, Version 2.0"
- "Licensed under the Ubuntu Font Licence 1.0."

Currently accepted licenses are Apache or Open Font License.
For a small set of legacy families the Ubuntu Font License may be acceptable as
well.

When in doubt, please choose OFL for new font projects.

* ⚠ **WARN** Please consider using HTTPS URLs at name table entry [plat=3, enc=1, name=13] [code: http-in-description] * ⚠ **WARN** Please consider using HTTPS URLs at name table entry [plat=3, enc=1, name=13] [code: http-in-description] * ⚠ **WARN** Please consider using HTTPS URLs at name table entry [plat=3, enc=1, name=13] [code: http-in-description] * ⚠ **WARN** For now we're still accepting http URLs, but you should consider using https instead. [code: http]

⚠ WARN: Are there caret positions declared for every ligature?

* [com.google.fonts/check/ligature_carets](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/ligature_carets)

--- Rationale ---

All ligatures in a font must have corresponding caret (text cursor) positions
defined in the GDEF table, otherwhise, users may experience issues with caret
rendering.

If using GlyphsApp, ligature carets can be set directly on canvas by accessing
the `Glyph -> Set Anchors` menu option or by pressing the `Cmd+U` keyboard
shortcut.

If designing with UFOs, (as of Oct 2020) ligature carets are not yet compiled
by ufo2ft, and therefore will not build via FontMake. See
googlefonts/ufo2ft/issues/329

* ⚠ **WARN** This font lacks caret position values for ligature glyphs on its GDEF table. [code: lacks-caret-pos]

⚠ WARN: Is there kerning info for non-ligated sequences?

* [com.google.fonts/check/kerning_for_non_ligated_sequences](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/kerning_for_non_ligated_sequences)

--- Rationale ---

Fonts with ligatures should have kerning on the corresponding non-ligated
sequences for text where ligatures aren't used (eg
https://github.com/impallari/Raleway/issues/14).

* ⚠ **WARN** GPOS table lacks kerning info for the following non-ligated sequences: - f + f - f + i - i + f - f + l - l + f - i + l [code: lacks-kern-info]

⚠ WARN: Checking Vertical Metric Linegaps.

* [com.google.fonts/check/linegaps](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/hhea.html#com.google.fonts/check/linegaps) * ⚠ **WARN** OS/2 sTypoLineGap is not equal to 0. [code: OS/2]

Summary

💔 ERROR	🔥 FAIL	⚠ WARN	💤 SKIP	ℹ INFO	🍞 PASS	🔎 DEBUG
3	2	6	85	8	90	0
2%	1%	3%	44%	4%	46%	0%

Note: The following loglevels were omitted in this report:

SKIP
INFO
PASS
DEBUG

kosmynkab / Brygada-1918

Post full FontBakery QA #6

Fontbakery report

Summary

PLOT_GLYPHS.zip