Google Fonts QA report

[m4rc1e]

Fontbakery report

Fontbakery version: 0.7.20

[1] Family checks

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

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

--- Rationale ---

There's no reasonable (and legal) way to run the command `ftxvalidator` of the
Apple Font Tool Suite on a non-macOS machine. I.e. on GNU+Linux or Windows etc.

If Font Bakery is not running on an OSX machine, the machine running Font
Bakery could access `ftxvalidator` on OSX, e.g. via ssh or a remote procedure
call (rpc).

There's an ssh example implementation at:
https://github.com/googlefonts/fontbakery/blob/master/prebuilt/workarounds/ftxvalidator/ssh-implementation/ftxvalidator

* ⚠ **WARN** ftxvalidator is not available.

[6] RobotoMono[wght].ttf

🔥 FAIL: A static fonts directory with at least two fonts must accompany variable fonts

* [com.google.fonts/check/repo/vf_has_static_fonts](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/googlefonts.html#com.google.fonts/check/repo/vf_has_static_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** Please create a subdirectory called "static/" and include in it static font files. [code: missing]

🔥 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 2163, but got 2146 instead [code: ascent]

🔥 FAIL: Checking correctness of monospaced metadata.

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

--- Rationale ---

There are various metadata in the OpenType spec to specify if a font is
monospaced or not. If the font is not trully monospaced, then no monospaced
metadata should be set (as sometimes they mistakenly are...)

Requirements for monospace fonts:

* post.isFixedPitch - "Set to 0 if the font is proportionally spaced, non-zero
if the font is not proportionally spaced (monospaced)"
  www.microsoft.com/typography/otspec/post.htm

* hhea.advanceWidthMax must be correct, meaning no glyph's width value is
greater.
  www.microsoft.com/typography/otspec/hhea.htm

* OS/2.panose.bProportion must be set to 9 (monospace). Spec says: "The PANOSE
definition contains ten digits each of which currently describes up to sixteen
variations. Windows uses bFamilyType, bSerifStyle and bProportion in the font
mapper to determine family type. It also uses bProportion to determine if the
font is monospaced."
  www.microsoft.com/typography/otspec/os2.htm#pan
  monotypecom-test.monotype.de/services/pan2

* OS/2.xAvgCharWidth must be set accurately.
  "OS/2.xAvgCharWidth is used when rendering monospaced fonts, at least by
Windows GDI"
  http://typedrawers.com/discussion/comment/15397/#Comment_15397

Also we should report an error for glyphs not of average width.

Please also note:
Thomas Phinney told us that a few years ago (as of December 2019), if you gave
a font a monospace flag in Panose, Microsoft Word would ignore the actual
advance widths and treat it as monospaced. Source:
https://typedrawers.com/discussion/comment/45140/#Comment_45140

* 🔥 **FAIL** On monospaced fonts, the value of OS/2.panose.bProportion must be set to 9 (proportion: monospaced), but got 0 instead. [code: mono-bad-panose-proportion] * ⚠ **WARN** Font is monospaced but 33 glyphs (3.277060575968222%) have a different width. You should check the widths of: ['hyphen', 'f', 'gravecomb', 'acutecomb', 'tildecomb', 'hook', 'uni030F', 'dotbelow', 'uni0483', 'uni0484', 'uni0485', 'uni0486', 'uni0488', 'uni0489', 'uni00AD', 'Dcroat', 'Eth', 'hbar', 'dcaron', 'lcaron', 'ldot', 'tcaron', 'Epsilontonos', 'Etatonos', 'Iotatonos', 'Omicrontonos', 'Upsilontonos', 'Omegatonos', 'exclamdbl', 'dcroat', 'uni20AB', 'uni049E', 'uni049F'] [code: mono-outliers]

⚠ WARN: Stricter unitsPerEm criteria for Google Fonts.

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

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

* ⚠ **WARN** Even though unitsPerEm (2048) in this font is reasonable. It is strongly advised to consider changing it to 2000, since it will likely improve the quality of Variable Fonts by avoiding excessive rounding of coordinates on interpolations. [code: legacy-value]

⚠ WARN: Font contains .notdef as first glyph?

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

--- Rationale ---

The OpenType specification v1.8.2 recommends that the first glyph is the
.notdef glyph without a codepoint assigned and with a drawing.

https://docs.microsoft.com/en-us/typography/opentype/spec/recom#glyph-0-the-notdef-glyph

Pre-v1.8, it was recommended that a font should also contain a .null, CR and
space glyph. This might have been relevant for applications on MacOS 9.

* ⚠ **WARN** Font should contain the .notdef glyph as the first glyph, it should not have a Unicode value assigned and should contain a drawing.

⚠ WARN: Does GPOS table have kerning information?

* [com.google.fonts/check/gpos_kerning_info](https://font-bakery.readthedocs.io/en/latest/fontbakery/profiles/gpos.html#com.google.fonts/check/gpos_kerning_info) * ⚠ **WARN** GPOS table lacks kerning information. [code: lacks-kern-info]

Summary

💔 ERROR	🔥 FAIL	⚠ WARN	💤 SKIP	ℹ INFO	🍞 PASS	🔎 DEBUG
0	3	4	80	8	71	0
0%	2%	2%	48%	5%	43%	0%

Note: The following loglevels were omitted in this report:

• SKIP
• INFO
• PASS
• DEBUG

Diff images: robotomono_qa.zip