I’m puzzled as to why the STAT Table has both Slant and Italic entries when I’m only using the Slant axis (slnt) in my .glyphs file. I noticed this inconsistency after a Font Bakery check flagged it.
com.google.fonts/check/italic_axis_in_stat_is_boolean
Check that the value of the 'ital' STAT axis is boolean (either 0 or 1), and elided for the Upright and not elided for the Italic, and that the Upright is linked to the Italic.
MyFont.ttf
WARN :
STAT table 'ital' axis has wrong value. Expected: 0, got '1.0'. [code: wrong-ital-axis-value]
WARN :
STAT table 'ital' axis flag is wrong. Expected: 2 (elided) Got: '0' [code: wrong-ital-axis-flag]
WARN :
STAT table 'ital' axis is not linked to Italic. [code: wrong-ital-axis-linkedvalue]
```
Oh, strange. I’ve just noticed this as well. I’ve set up only a Slant axis in my Glyphs source, but a Glyphs VF export has inserted an Italic axis into the STAT table. This has happened even though the fvar only includes the Weight and Slant axes, as expected.
I’ve been having the same problem here on a wght+slnt family.
A few days ago I didn’t know much about STAT tables, but I think I’ve somewhat wrapped my head around this. The STAT table contains defined positions for each axis, so if the font has an ital axis and contains both Roman and Italic styles, two positions will be defined (ital=0, ital=1). Usually each axis has at least 2 positions defined, which correspond with the interpolable range of values on that axis, but ital sometimes has only 1 value. This happens when a variable font family has separate files for Roman and Italic, then they should each contain only one axis value (ital=0 in the Roman, ital=1 in the Italic).
All three warnings we’re seeing essentially mean that Fontbakery has identified a single-value ital axis in the font, but the value, flag, and style link are indicating that the font is Italic, which raises this warning because Fontbakery doesn’t see any other evidence that the font is Italic (I believe it checks for italic keywords in the name table and checks for a non-zero italicAngle property).
So, if I’ve got that all correct, then I’m perplexed why Glyphs is adding a single-value ital axis (implying the font contains Roman or Italic) in the first place, when a slnt axis is present (implying the font has Roman and Italic).
Nothing wrong with that though it ought to be ital=0. The ital definition should always be there so a UI knows whether to treat this font as a Roman/Upright or as a (potentially style-linked) Italic.
If you intend to use your slnt maximum as the Italic, then slnt is the wrong axis to use. Should be ital, with a range from 0 to 1 (can be solved with axis location parameters).
Or, you define your own STAT table:
Make sure you have a variable font setting in File > Font Info > Exports, and export once as variable font.
Run Script > mekkablue > Post Production > Read and Write STAT Axis Values
Go to File > Font Info > Exports, pick your variable font setting and edit the Axis Values custom parameters the script just created:
One parameter per axis, always start with the axis tag, followed by a semicolon, then define the axis positions always with the scheme value=Name, e.g. 300=Light, separate them with commas. The word Regular gets an asterisk, marking it as elidable, e.g., 100=Regular* for the Width axis. Style linking is done with value>linkedValue, always for the regular/normal value, e.g., 400>700=Regular*, linking 700 (Bold) to 400 (Regular) on the Weight axis.
Run the script again, now it will look for the latest VF export and overwrite the STAT table. Detailed report in the Macro Window.
My advice: Keep your ital axis but with ital; 0=Regular*
These are some really interesting details, Rainer – thanks for providing more context here! I don’t quite know what to think about it so far.
I am still slightly surprised that the Italic axis is indicated in the STAT table, and doubly surprised to realize that it’s indicated as being at a value of 1. Is that indicating an expectation that there would be a more “roman” counterpart to such a font? Or, does setting it to 1 somehow make the Italic style linking work within the single, wght+slnt variable font?
That probably means that your VF origin has an Italic Angle other than 0. You can try adding an italicAngle parameter (value 0) to your Variable Font Setting or an Italic Style Linking parameter.
I still have some issues with the STAT table, even after trying all your suggestions.
com.google.fonts/check/STAT_strings
Check correctness of STAT table strings
Rationale:
On the STAT table, the "Italic" keyword must not be used on AxisValues for variation axes other than 'ital'.
More info: https://github.com/fonttools/fontbakery/issues/2863
FAIL The following AxisValue entries on the STAT table should not contain "Italic": ['nameID 356: Italic'] [code: bad-italic]
com.google.fonts/check/italic_axis_in_stat_is_boolean
Ensure ‘ital’ STAT axis is boolean value
Rationale:
Check that the value of the 'ital' STAT axis is boolean (either 0 or 1), and elided for the Upright and not elided for the Italic, and that the
Upright is linked to the Italic.
More info: https://github.com/fonttools/fontbakery/issues/3668
WARN STAT table 'ital' axis has wrong value. Expected: 0, got '1.0'. [code: wrong-ital-axis-value]
WARN STAT table 'ital' axis flag is wrong. Expected: 2 (elided) Got: '0' [code: wrong-ital-axis-flag]
WARN STAT table 'ital' axis is not linked to Italic. [code: wrong-ital-axis-linkedvalue]
NOTE : If I disable all my italic instances, theses checks pass.
Does anyone have a link to an open-source font where these checks don’t fail?
What exactly is your setup? Your italic masters & instances should have ital 1, all roman instances ital 0. The error above suggests that somehow an italic instance had ital=0.
So you cannot use the “slant” axis (in order to make the slant variable instead of a binary switch) and still call the instances “Italic” which the users would understand better? I think I do not want to call my italic fonts “Slanted”, even though I also want to generate a variable font that is not binary italic. Or did I misunderstand that?
That Fontbakery check is for the Google Fonts ecosystem, if I understand correctly. The OpenType spec doesn’t require “Italic” names to be used only for the ital axis, does it? Type designers frequently use “Italic” to name the oblique/slanted styles in their family, because it’s all “italic” to most end users.
That would prevent the end user from choosing their slant angle, and I don’t think the ital axis is meant to be used that way. The spec seems to strongly imply that ital is for “true” italics that don’t interpolate, and slnt is for oblique italics that do interpolate.
Also, if you’re building a variable family with interpolable italics, you need to use slnt if you want maximum support in web browsers. Only Firefox has good support for ital.
I meant the specific check inside of Fontbakery that Hugo mentioned:
That check is in Fontbakery’s Google Fonts profile. It allows the “Italic” keyword to be used only on ital axes.
There’s a different STAT_strings check (com.adobe.fonts/check/STAT_strings) in the Adobe Fonts profile, which is also used in the Type Network profile. That check allows the “Italic” keyword to be used on ital or slnt axes.
Fontbakery’s “Universal” profile is meant to perform checks based on established best practices. It currently includes the Google Fonts STAT_strings check, but there was some discussion about changing it to the more lenient Adobe STAT_strings check.
