[com_adobe_fonts_check_consistent_font_family_name] failures
Observed behaviour
After upgrading to Fontbakery v0.8.13 a lot of our families started failing on the com_adobe_fonts_check_consistent_font_family_name check in the adobefonts profile. This looks related to families that style link non-RIBBI styles.
The situation is as follows:
| style | nameID 1 | nameID 2 | nameID 16 | nameID 17 |
|---|---|---|---|---|
| Georgia Italic | Georgia | Italic | [n/a] | [n/a] |
| Georgia | Georgia | Regular | [n/a] | [n/a] |
| Georgia Light | Georgia Light | Regular | Georgia | Light |
| Georgia Light Italic | Georgia Light | Italic | Georgia | Light Italic |
In this case the check outputs a FAIL with the following message:
* 'Georgia' was found in:
- Georgia-Light_Italic.ttf (nameID 16)
- Georgia-Regular_Italic.ttf (nameID 1)
- Georgia-Light.ttf (nameID 16)
- Georgia-Regular.ttf (nameID 1)
Expected behaviour
I'm not sure what the intention of the check is. It quotes the OT spec:
Per the OpenType spec:
* "...many existing applications that use this pair of names assume that a
Font Family name is shared by at most four fonts that form a font
style-linking group"
* "For extended typographic families that includes fonts other than the
four basic styles(regular, italic, bold, bold italic), it is strongly
recommended that name IDs 16 and 17 be used in fonts to create an extended,
typographic grouping."
* "If name ID 16 is absent, then name ID 1 is considered to be the typographic
family name."
https://learn.microsoft.com/en-us/typography/opentype/spec/name
Fonts within a font family all must have consistent names
in the Typographic Family name (nameID 16)
or Font Family name (nameID 1), depending on which it uses.
Inconsistent font/typographic family names across fonts in a family
can result in unexpected behaviors, such as broken style linking.
But the above behaviour is explicitly allowed by the quoted section, so I wouldn't expect this to fail. The family in question uses style linking in nameID 1 & 2 correctly and uses nameID 16 & 17 to create "extended typographic groupings". Per the last bullet point, the font compiler is also allowed to leave out nameID 16 if it is the same as nameID 1.
@miguelsousa Perhaps you could shed some light on this issue?
This check was added recently by @kaydeearts. Its proposal is #4112. I don't see anything wrong with how the family in your example is named. I think there might be a flaw in the check's implementation.
Kamile, can you look into this?
@bramstein thanks for submitting this issue! I agree with Miguel, the family names sound good based on what you described. It only cares if nameID 16 or nameID 1 are all consistent across the family, and what you describe follows this.
I tried to reproduce your issue by changing the name table of Source Sans Pro test fonts, attached in the zip file below. However, I haven't been able to replicate it. Is this the only failure output you're seeing?
I'm finding it odd that it's only complaining about 'Georgia' βΒ usually when there are more than one typographic/font family names found, it will print a list of two or more names that it found. The fact that its printing only one is strange. For instance, when I change Georgia-Italic.otf's nameID 1 to 'Georgiala', it fails and prints a list of two names: 'Georgiala' and 'Georgia':
FAIL 2 different Font Family names were found:
β’ 'Georgiala' was found in:
β’ Georgia-Italic.otf (nameID 1)
β’ 'Georgia' was found in:
β’ Georgia-Light-Italic.otf (nameID 16)
β’ Georgia-Light.otf (nameID 16)
β’ Georgia-Regular.otf (nameID 1) [code: inconsistent-family-name]
Are there any more details you could give me regarding the name table? Perhaps there are multiple entries for nameID 16 and/or 1 but with different platformID/encodingID/languageID?
I've attached the test fonts I made here:
georgia-test.zip
If you're seeing any key differences between your font family vs that test font family, please let me know and I'll continue testing. Thank you!
@kaydeearts Thanks for your reply and sorry for the delay in getting back to you (holiday and such!)
I did a bit more digging, and I think the name table identifiers are a red-herring. I think the real problem is that the check assumes that subfamilies are tested in separate Font Bakery runs. For example, the test fails if I run Font Bakery on a directory containing all styles in the family:
$ tree GeorgiaPro
GeorgiaPro
βββ Georgia_Pro-Black_Italic.otf
βββ Georgia_Pro-Black.otf
βββ Georgia_Pro-Bold_Italic.otf
βββ Georgia_Pro-Bold.otf
βββ Georgia_Pro-Condensed_Black_Italic.otf
βββ Georgia_Pro-Condensed_Black.otf
βββ Georgia_Pro-Condensed_Bold_Italic.otf
βββ Georgia_Pro-Condensed_Bold.otf
βββ Georgia_Pro-Condensed_Italic.otf
βββ Georgia_Pro-Condensed_Light_Italic.otf
βββ Georgia_Pro-Condensed_Light.otf
βββ Georgia_Pro-Condensed.otf
βββ Georgia_Pro-Condensed_Semi_Bold_Italic.otf
βββ Georgia_Pro-Condensed_Semi_Bold.otf
βββ Georgia_Pro-Italic.otf
βββ Georgia_Pro-Light_Italic.otf
βββ Georgia_Pro-Light.otf
βββ Georgia_Pro-Regular.otf
βββ Georgia_Pro-Semi_Bold_Italic.otf
βββ Georgia_Pro-Semi_Bold.otf
This produces the following output:
FAIL 2 different Font Family names were found:
β’ 'Georgia Pro' was found in:
β’ Georgia_Pro-Black_Italic.otf (nameID 16)
β’ Georgia_Pro-Black.otf (nameID 16)
β’ Georgia_Pro-Bold_Italic.otf (nameID 1)
β’ Georgia_Pro-Bold.otf (nameID 1)
β’ Georgia_Pro-Italic.otf (nameID 1)
β’ Georgia_Pro-Light_Italic.otf (nameID 16)
β’ Georgia_Pro-Light.otf (nameID 16)
β’ Georgia_Pro-Regular.otf (nameID 1)
β’ Georgia_Pro-Semi_Bold_Italic.otf (nameID 16)
β’ Georgia_Pro-Semi_Bold.otf (nameID 16)
β’ 'Georgia Pro Condensed' was found in:
β’ Georgia_Pro-Condensed_Black_Italic.otf (nameID 16)
β’ Georgia_Pro-Condensed_Black.otf (nameID 16)
β’ Georgia_Pro-Condensed_Bold_Italic.otf (nameID 1)
β’ Georgia_Pro-Condensed_Bold.otf (nameID 1)
β’ Georgia_Pro-Condensed_Italic.otf (nameID 1)
β’ Georgia_Pro-Condensed_Light_Italic.otf (nameID 16)
β’ Georgia_Pro-Condensed_Light.otf (nameID 16)
β’ Georgia_Pro-Condensed.otf (nameID 1)
β’ Georgia_Pro-Condensed_Semi_Bold_Italic.otf (nameID 16)
β’ Georgia_Pro-Condensed_Semi_Bold.otf (nameID 16) [code:
inconsistent-family-name]
If I split up the family into two directories grouped by width (e.g. regular and condensed) and run Font Bakery separately on each directory the test passes.
$ tree GeorgiaPro
βββ Georgia Pro
βΒ Β βββ Georgia_Pro-Black_Italic.otf
βΒ Β βββ Georgia_Pro-Black.otf
βΒ Β βββ Georgia_Pro-Bold_Italic.otf
βΒ Β βββ Georgia_Pro-Bold.otf
βΒ Β βββ Georgia_Pro-Italic.otf
βΒ Β βββ Georgia_Pro-Light_Italic.otf
βΒ Β βββ Georgia_Pro-Light.otf
βΒ Β βββ Georgia_Pro-Regular.otf
βΒ Β βββ Georgia_Pro-Semi_Bold_Italic.otf
βΒ Β βββ Georgia_Pro-Semi_Bold.otf
βββ Georgia Pro Condensed
βββ Georgia_Pro-Condensed_Black_Italic.otf
βββ Georgia_Pro-Condensed_Black.otf
βββ Georgia_Pro-Condensed_Bold_Italic.otf
βββ Georgia_Pro-Condensed_Bold.otf
βββ Georgia_Pro-Condensed_Italic.otf
βββ Georgia_Pro-Condensed_Light_Italic.otf
βββ Georgia_Pro-Condensed_Light.otf
βββ Georgia_Pro-Condensed.otf
βββ Georgia_Pro-Condensed_Semi_Bold_Italic.otf
βββ Georgia_Pro-Condensed_Semi_Bold.otf
I think I understand why the check was written, but it doesn't fit with the rest of the Font Bakery checks which run on an entire family (for example, the checks that verify vertical metrics are consistent across a family).
Perhaps a fix would be to check that prefixes match within a family? That would allow Georgia and Georgia Condensed (and all the other subfamilies), while still rejecting families that don't share a prefix.
@kaydeearts Could you take another look at this? Thanks!
Thanks for the ping @bramstein! I'll take another look and respond to you soon.
@bramstein I'm back to my usual job duties after being busy preparing for Adobe MAX, so thank you for your patience!
I agree with you about the subfamilies being tested together. I thought about this a bit and how we could avoid causing future issues with the many edge cases that are possible here. Spoke with @josh-hadley a bit as well!
I tried something out on this branch β it's difficult to be able to tell what part of the family name 'should' and 'shouldn't' be the prefix, so I thought we could try checking only if the first word in the names are the same. Let me know if you have any thoughts on that. Thanks!
Hi @bramstein ! Happy New Year, hope you are well! I wanted to check in to see if you were able to try the changes in that branch yet, and if this is still an issue? Thanks!