port checks from the AFDKO comparefamily tool to FontBakery

[cjchapman]

As Thomas Phinney mentioned in the TypeCon 2018 MFDOS meeting: it would be great to include checks from the AFDKO comparefamily tool in FontBakery.

Here's a link to the code in GitHub: https://github.com/adobe-type-tools/afdko/blob/develop/python/afdko/comparefamily.py

[cjchapman]

We have this related issue in the AFDKO repo: https://github.com/adobe-type-tools/afdko/issues/501

I'm happy to work with you all to port the checks from the AFDKO into a FontBakery specification.

[felipesanches]

A first step here would be to list all the available checks giving them a short name as well as a longer rationale description. With that we can decide which id to use for each check. But they should probably be called something like com.adobe/check/keyword or maybe com.adobe.typetools/check/keyword or even com.adobe.type/check/keyword

Then we can write the boilerplate for these new checks and start refactoring snippets of the code into the boilerplate.

And finally we'd ideally expect code-tests to ensure the checks work properly I can help with that as well.

[felipesanches]

@cjchapman Please take a look at the example of porting a check from AFDKO into FontBakery that I have just pushed on pull request #2064

Please let me know if you have doubts on the code-style and architecture.

[felipesanches]

Also we should write code-tests. I may take some time to also write an example of that here later next week.

[felipesanches]

@cjchapman Also, it is important to understand the rationale behind these check routines. For instance, the first one that I ported is lacking a description of why 63 is the longest allowed string length for name id 18 and also why the strings should be unique in their first 32 characteres.

Which specific software requires that? What kind of problem is know to be caused by fonts that do not respect those requirements? We should be collecting this kind of info and placing it in the "rationale" field of the @check decorator.

[felipesanches]

These are all of the "single face tests" in AFDKO's comparefont.py:

• SingleTest 1: Length overrun check for name ID 18. Max 63 characters, must be unique within 31 chars.
• SingleTest 2: Length overrun check for name ID's 1,2, 4, 16, 17. Max 63 characters.
• SingleTest 3: Check that name ID 4 (Full Name) starts with same string as Preferred Family Name, and is the same as the CFF font Full Name.
• SingleTest 4: Version name string matches release font criteria and head table value
• SingleTest 5: Check that CFF PostScript name is same as name table name ID 6.
• SingleTest 6: Check that Copyright, Trademark, Designer note, and foundry values are present, and match default values.
• SingleTest 7: Checking for deprecated CFF operators.
• SingleTest 8: Check SubFamily Name (name ID 2) for Regular Style, Bold Style, Italic Style, and BoldItalic Style.
• SingleTest 9: Check that no OS/2.usWeightClass is less than 250
• SingleTest 10: Check that no Bold Style face has OS/2.usWeightClass of less than 500
• SingleTest 11: Check that BASE table exists, and has reasonable values (rationale: BASE table is necessary for users who are editing in a different script than the font is designed for.)
• SingleTest 12: Check that Italic style is set when post table italic angle is non-zero, and that italic angle is reasonable.
• SingleTest 13: Warn if post.isFixedPitch is set when font is not monospaced.
• SingleTest 14: Warn if Bold/Italic style bits do not match between the head Table and OS/2 Table
• SingleTest 15: Warn if Font BBox x/y coordinates are improbable, or differ between head table and CFF.
• SingleTest 16: Check values of Ascender and Descender vs em-square.
• SingleTest 17: Verify that all tabular glyphs have the same width.
• SingleTest 18: Hint Check. Verify that there is at least one hint for each charstring in each font, and that no charstring is > 32K limit for Mac OSX 10.3.x and earlier.
• SingleTest 19: Warn if the Unicode cmap table does not exist, or there are double mapped glyphs in the Unicode cmap table
• SingleTest 20: Warn if there are double spaces in the name table font menu names.
• SingleTest 21: Warn if there trailing or leading spaces in the name table font menu names.
• SingleTest 22: Warn if any ligatures have a width which not larger than the width of the first glyph, or, if first glyph is not in font, if the RSB is negative.
• SingleTest 23: Warn if any accented glyphs have a width different than the base glyph.
• SingleTest 24: Warn if font has 'size' feature, and design size is not in specified range.
• SingleTest 25: Check that fonts do not have UniqueID, UID, or XUID in CFF table.
• SingleTest 26: Glyph name checks.
• SingleTest 27: Check strikeout/subscript/superscript positions.
• SingleTest 28: Check font OS/2 code pages for the a common set of code page bits.
• SingleTest 29: Does nothing!
• SingleTest 30: Check that there are no more than 7 pairs of BlueValues and FamilyBlues in a font, and there is an even number of values.
• SingleTest 31: Check that there are no more than 5 pairs of OtherBlues and FamilyOtherBlues in a font, and there is an even number of values.
• SingleTest 32: Check that all fonts have blue value pairs with first integer is less than or equal to the second integer in pairs.
• SingleTest 33: Check that Bottom Zone blue value pairs and Top Zone blue value pairs are at least (2*BlueFuzz+1) unit apart in a font.
• SingleTest 34: Check that the difference between numbers in blue value pairs meet the requirement.

[felipesanches]

And these are all of the "family tests":

• Family Test 1: Verify that each group of fonts with the same nameID 1 has maximum of 4 fonts.
• Family Test 2: Check that the Compatible Family group has same name ID's in all languages except for the compatible names 16,17,18, 20, 21 and 22.
• Family Test 3: Check that the Compatible Family group has same Preferred Family name (name ID 16)in all languagesID 16 in all other languages.
• Family Test 4: Family-wide 'size' feature checks.
• Family Test 5: Check that style settings for each face is unique within Compatible Family group, in all languages.
• Family Test 6: Check that the Compatible Family group has a base font and at least two faces, and check if weight class is valid.
• Family Test 7: Check that all faces in the Preferred Family group have the same Copyright and Trademark string.
• Family Test 8: Check the Compatible Family group style vs OS/2.usWeightClass settings. Max 2 usWeightClass allowed.
• Family Test 9: Check that all faces in the Compatible Family group have the same OS/2.usWidthClass value.
• Family Test 10: Check that if all faces in family have a Panose number and that CFF ISFixedPtch matches the Panose monospace setting.
• Family Test 11: Check that Mac and Windows menu names differ for all but base font, and are the same for the base font.
• Family Test 12: Check that GSUB/GPOS script and language feature lists are the same in all faces, and that DFLT/dflt and latn/dflt are present.
• Family Test 13: Check that no two faces in a preferred group have the same weight/width/Italic-style values when the OS/2 table fsSelection bit 8 (WEIGHT_WIDTH_SLOPE_ONLY) is set.
• Family Test 14: Check that all faces in a preferred group have the same fsType embedding values.
• Family Test 15: Check that all faces in a preferred group have the same underline position and width.
• Family Test 16: Check that for all faces in a preferred family group, that the width of any glyph is not more than 3 times the width of the same glyph in any other face.
• Family Test 17: Check that fonts have OS/2 table version 4.
• Family Test 18: Check that all faces in a Compatible Family group have the same array size of BlueValues and OtherBlues within a Compatible Family Name Italic or Regular sub-group of the family.
• Family Test 19: Check that all faces in the Preferred Family group have the same values of FamilyBlues and FamilyOtherBlues, and are valid.
• Family Test 20: Check that all faces in the Compatible Family group have the same BlueScale value.
• Family Test 21: Check that all faces in the Compatible Family group have the same BlueShift value.

[felipesanches]

We should document the reasoning behind each of all of these checks ;-)

It seems that some of those are similar to checks we already have in the Google Fonts specification. So it would also be nice to compare and understand case-by-case why do we sometimes have slightly different criteria.

[felipesanches]

@miguelsousa and @cjchapman, here are some thoughts abour SingleTest 1 ("Length overrun check for name ID 18. Max 63 characters, must be unique within 31 chars."):

• It is not really a single-font check since it compares the data of multiple font files to make sure they are all coherent (nameid 18 uniqueness).
• Also it seems it is checking 2 different things (uniqueness and max length) So, for the sake of making is simple-to-read, I'd suggest splitting it into 2 separate checks.
• And then both portions of the check would need some more detailed description of their purpose.

[felipesanches]

Please note that the example of porting the "SingleTest 1" check into Font Bakery is probably incorrectly implemented. Use that example only as a demonstration of the API and code style, but the actual implementation should be reviewed and fixed (for instance, taking care of issues like what I described in my previous comment above: https://github.com/googlefonts/fontbakery/issues/1992#issuecomment-427253635)

[tphinney]

Fwiw, I know the rationale for a lot of the ”unexplained” checks. I could spend some time going over these. Some are simply spec-based. Others are due to app or OS limitations.

[tphinney]

To discuss individual checks, I could:

• create a shared spreadsheet with a line for each item, or
• create separate issues, one for each item
• or...?

Preferences?

[felipesanches]

I'd prefer a shared spreadsheet to begin with and then gradually open individual issues for each proposed new check only when we feel it is worthy working on them (i.e. after we figure out good check-id, rationale, etc) so that an individual issue would be actually ready for someone to fix.

[tphinney]

I’m starting a spreadsheet. Once I have added enough commentary to be interesting, I will share the link and we can discuss.