You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the issue
There are situations where we may want to add more instances to a font without affecting how instances are cut in the pipeline.
Having the "optional fallback" in the axis definitions would allow that and also serve as a standard for those instance names that are not covered by "fallback" entries. Example
Consider a case where a font has a range of 1-1000 in the weight axis, but the axis registry only covers the range 100-900.
The 1 and 1000 instances are not defined in the axis registry, so we don't name those extremes in the font. However, if we don't, then our min and max for this axis in the STAT table will be uncovered. In this case, using a range in the STAT is also not appropriate - too big of a range.
This is being checked by FB here https://font-bakery.readthedocs.io/en/stable/fontbakery/profiles/googlefonts.html#com.google.fonts/check/STAT
To address that fail, we could introduce new instances that are not defined in the axis registry, which is not ideal, as we would introduce something that is not standardised. At the same time, we might not introduce more "fallback" entries. This is where "optional fallback" for additional instances would come in handy. If 1 "Hairline" and something like 1000 "UltraBlack" or "UltraHeavy" are defined as optional fallbacks, we have a standard name for this place on the axis but, at the same time, wouldn't cut too many static instances.
It could be even more helpful for novelty and custom axes.
The text was updated successfully, but these errors were encountered:
For font families ranging from 1 to 1000 in the wght axis, such as Sofia Sans, the STAT table can include a Hairline definition for weight 1 and an ExtraBlack for 1000. Even though these instances will not be included in the zip file, users can still access them by setting the appropriate value when using the VF.
However, this means some mismatch between the fvar and STAT instances will be accepted in these cases, and the reported FB Fail will be admitted.
I've created a PR to the Guide detailing these special cases.
Describe the issue
There are situations where we may want to add more instances to a font without affecting how instances are cut in the pipeline.
Having the "optional fallback" in the axis definitions would allow that and also serve as a standard for those instance names that are not covered by "fallback" entries.
Example
Consider a case where a font has a range of 1-1000 in the weight axis, but the axis registry only covers the range 100-900.
The 1 and 1000 instances are not defined in the axis registry, so we don't name those extremes in the font. However, if we don't, then our min and max for this axis in the STAT table will be uncovered. In this case, using a range in the STAT is also not appropriate - too big of a range.
This is being checked by FB here https://font-bakery.readthedocs.io/en/stable/fontbakery/profiles/googlefonts.html#com.google.fonts/check/STAT
To address that fail, we could introduce new instances that are not defined in the axis registry, which is not ideal, as we would introduce something that is not standardised. At the same time, we might not introduce more "fallback" entries. This is where "optional fallback" for additional instances would come in handy. If 1 "Hairline" and something like 1000 "UltraBlack" or "UltraHeavy" are defined as optional fallbacks, we have a standard name for this place on the axis but, at the same time, wouldn't cut too many static instances.
It could be even more helpful for novelty and custom axes.
The text was updated successfully, but these errors were encountered: