Checks related to style-linking and fsSelection seem to be disabled.

[mgbella]

Observed behaviour

I (manually) found that the fonts I was QA-ing did not have style linking enabled, but the checks below did not report them. Are they disabled?

com.google.fonts/check/fsselection
com.google.fonts/check/mac_style
com.fontwerk/check/style_linking

(Describe the results you're getting)
No FAIL is reported when it should be. In fact, there is no mention of the above checks when running several profiles, eg. Adobe, TN, Universal.
Here is an example of the incorrect naming, but there was no report of a FAIL. (I hid the real name.)

Expected behaviour

I expected a FAIL on fsSelection, mac_style, and even the names.

(Describe what you expected to happen, or wished was different)
Please reinstate the checks. Consider consolidate the checks or just using com.fontwerk/check/style_linking and modify this check to include a test for Bold.

Resources and steps needed to reproduce

I'm not able to share the fonts but run any fonts without RIBBI style-linking where you expect the checks to report FAILS and you'll notice they are missing from the reports in several FB profiles.

I'm using the latest Fontbakery version 0.12.10.

(Provide the font file that causes the issue, and the exact steps to reproduce it. Also mention the FontBakery version you're using, and some details about your system, e.g. OS, Python version, etc.)

[felipesanches]

Note: there was a simplification of check-IDs last week, removing the reverse domain prefix in them, so I'll mention the new IDs below. I believe that this change helps to clarify the structure of the profiles (the reverse domains were apparently causing confusion among users). Please take a look at the profile definition files at https://github.com/fonttools/fontbakery/tree/main/Lib/fontbakery/profiles and I hope you agree with me that it is much easier to understand now. Please let me know what you think.

These two checks (now simply called opentype/mac_style and opentype/fsselection)
are in the OpenType profile, so they end up included in all profiles:

• com.google.fonts/check/fsselection
• com.google.fonts/check/mac_style

This one is now called fontwerk/style_linking and is on the Fontwerk profile, and it is also adopted by the Typenetwork profile:

• com.fontwerk/check/style_linking

[felipesanches]

Also, since 2 different profiles pick the style_linking check, it may be reasonable to remove the fontwerk/ prefix from its checkid and move it to the Universal profile.

[felipesanches]

In my local testing I can see these checks running when I use --verbose. So, the issue may be that you don't see them because they are all resulting in PASS (which seems to be a bug) and then being omitted by the report that (by default) only outputs checks that do not pass.

So, we should double check each individual check, to see if their behavior is not correctly implemented.

If you can confirm that, then we can work on the specific fixes for each of these checks.

[mgbella]

Hi @felipesanches,
Thanks for looking into this. It turns out the fsSelection and mac_style checks were run correctly and did indeed pass. The error was in a duplicated style name (Bold) in both Family Name ID 1 and Style Name ID 2.

This broke the style-linking in Mac and Adobe apps. The error is correctly reported in Check ID: <FontBakeryCheck:com.google.fonts/check/font_names> , which is in both the Google and FontWerk FB profiles.
This check, based on #3800, may need to be modified for the Universal profile. Is there a check that checks for duplicated "style" words?—occurring in both Name IDs 1 and 2?