Open glenda-tn opened 1 year ago
Any update on this? Fonts are failing and it is not a fail to have Regular, Bit 6 unchecked for a style that is Light, Black, SemiBold, etc. The bit should be clear for anything but RIBBI.
Checking OS/2 fsSelection value. Check ID: <FontBakeryCheck:com.google.fonts/check/fsselection> π₯ FontName-Light.ttf π₯ FAIL OS/2 fsSelection REGULAR bit should be set. [code: bad-REGULAR]
Hello @felipesanches.
This check is continuing to report FAILS on all non-RIBBI styles and it shouldn't. -glenda
@RosaWagner, do you know if we're supposed to expect something different on Google Fonts?
I'm not sure which approach to take here. I surely can implement the change suggested by @glenda-tn for the Universal profile and maybe that's good for everybody.
And in case Google Fonts has a different approach then I can also customize the check for the gfonts profile. What do you think?
Reading again now the extended definition for this bit in the OT 19, I don't think this should be different on Google Fonts. @m4rc1e?
I agree with @vv-monsalve, and also to ask @m4rc1e's confirmation.
Thank you for looking into this. For easy reference @m4rc1e, here is the text from OT Spec 19:
Bit 6: Bit 6 is not used in widely used in modern applications. If bit 6 is set, then bits 0 and 5 must be clear, else the behavior is undefined. Note that, if both bit 0 and bit 5 are clear, that does not give any indication as to whether or not bit 6 will be clear. For example, Arial Light is not the regular style of Arial and would have all bits cleared. In extended font families, bit 6 does not need to be set for fonts other than the regular style that, nonetheless, use "Regular" for name ID 2. (See Name IDs for more information.)
Hello. Will there be movement on this? This is a reported as a FAIL when it's not a fail. The Regular fsSelection bit #6
does not need to be explicitly set for any other style except a real Regular
.
π₯ Font-Light.ttf π₯ FAIL OS/2 fsSelection REGULAR bit should be set. [code: bad-REGULAR]
π₯ Font-SemiBold.ttf π₯ FAIL OS/2 fsSelection REGULAR bit should be set. [code: bad-REGULAR]
Name ID 2 as Regular is just fine and expected, but not the fsSelection value. If you will not be changing this, we will do so in the Type Network profile. I brought it up here because I believe it should be updated for all profiles.
Thank you.
Oooops! Sorry, @glenda-tn! I'll review this today and try to address it!
Thank you @felipesanches!
@glenda-tn, My past couple weeks were too busy. But I finally was able to allocate some time to this issue. I'm now drafting a detailed rationale description for this check, trying to make it clear to every user what are all the considerations behind these checking criteria. I'll probably have something ready for review during next week.
(NOTE: Please include the check-id on the issue title. Check-id example [com.google.fonts/check/metadata/parses])
Observed behaviour
Fonts that are non-RIBBI styles with Bit 6-Regular unset fail. However, it is not a fail because it is not a requirement per OT Spec 19. I had created an Issue #936 with MS on the ambiguous wording in the spec last Summer 2022. @PeterCon did some research and found that modern applications do not use this particular bit, unlike the others (Bit 0-italic; bit 5-bold; 9-oblique; and of course, bit 7-USE_TYPO_METRICS.)
Issue #2444 sets the bit, but really it is acceptable to be unset.
Expected behaviour
If bit 6-Regular is not set for non-RIBBI styles, the check should PASS.
If it is Google's requirement to set bit 6 for non-RIBBI styles, then the check should be moved from the Universal profile to the Google profile.
(Describe here what you expected to happen, or what you wish was different)
It should not be a FAIL if the Regular Bit 6 is not set for non-RIBBI styles (eg Thin, Medium, SemiBold, etc.)
Resources and exact process needed to replicate
Unfortunately, I'm not able to share fonts that fail but if you take NotoSans-ExtraBold and uncheck the bit, you'll get the error.
(Please provide here an URL to a font file that appears to cause the issue, and the exact steps from updating to the latest code on the
main
branch to reproduce the Observed Behaviour. We need this in for replicating the issue and fixing it :)