GF profile: Vertical metrics check results should report if bit 7 is set

[davelab6]

In a call with @m4rc1e and @RosaWagner today, Marc asked if a font has the bit 7 set for the vertical metrics and the FB result didn't tell us; it would be convenient to report this status.

[felipesanches]

If I'm not mistaken, com.google.fonts/check/vertical_metrics_regressions does report this problem:

[felipesanches]

The policy established 3 years ago at #1162 seems to have been in favor of a FAIL if a font lacks bit 7 while a previous version was already publish with the bit set. Is there a new policy for making bit seven mandatory on all fonts? Or at least on new ones?

[felipesanches]

I was not able to find a recent Charis-SIL pull request on google/fonts repo, so I presume this report was generated privately (or I simply couldn't find it on a quick search on public repos). Where can I get samples of these font files to test fontbakery?

[RosaWagner]

It's because we are still talking about it in an issue: google/fonts#3757 (comment)

Current policy is to have the bit 7 enable to all new families except CJK. (#3241 (comment))

The context of SIL fonts is a bit particular, but what it shows here is that it would be good information to know if the bit is enabled or not, regardless of all other factors, when the win metrics check fails (as an additional argument). Indeed, if the bit is enabled, I can't find reasons to have these metrics unmatching y-min/max.

Context: in very rare cases we may find it acceptable to have non-matching win metrics if the bit 7 is not set, and can't be set (for eg. arabic open source font that has to match with the version served by an OS). So this shouldn't enter as a condition, but the information about the bit could help making a decision for rare exceptions.