Hi guys,
I run some tests with FontBakery for Adobe and I don’t quite understand this:
While I generate VF font, there are no any instances. How can I set this value of 400 to the “Regular”?
Or another Error:
Again, there are no instances so how they should have the same size?
And the last one:
I don’t know how to solve these. Please, help.
Thanks.
Michał
I’m having the same problems. But I can say that I could fix some issues adding a custom parameter “Axis Location” on each instances. I don’t know if is the correct method.
Example:
{
customParameters = (
{
name = "Axis Location";
value = (
{
Axis = Weight;
Location = 200;
},
{
Axis = Width;
Location = 100;
}
);
}
);
}```Some fontbakery checks are rather specific for a certain font vendor, in this case Google, and not valid universally, so you have to decide if they apply to your case.
If you don’t have an instance called “Regular”, you can ignore the first error message.
The last check seems relevant though; per the OpenType spec, the values of the weight axis should range from 1 to 1000 maximum (usually not that full range, but corresponding to the weights your font supports), so a default value of 0.0 for the weight axis shouldn’t happen. Adding axis locations as @beppeartz suggested should solve that.
I’m not sure how to influence the PostScript naming thing from within Glyphs.
I’ll have a look at the instance records.
You need to add the axis location parameters.
Ok guys, many thanks. I got rid of these errors, when I added instances:
but more errors keep popping up…
Why is STAT table missing Axis Value?
You need more instances at all corners of the design space.
I have the same problem, fontbakery gives a FAIL for a variable font (45 styles):
STAT table has Axis Value tables?
Rationale:
According to the OpenType spec, in a variable font, it is strongly
recommended that axis value tables be included for every element of
typographic subfamily names for all of the named instances defined in the
'fvar' table.
Axis value tables are particularly important for variable fonts, but can
also be used in non-variable fonts. When used in non-variable fonts, axis
value tables for particular values should be implemented consistently
across fonts in the family.
https://docs.microsoft.com/en-us/typography/opentype/spec
/stat#axis-value-tables
FAIL STAT table is missing Axis Value for 'wdth' value
'50.0' [code: missing-axis-value-table]
FAIL STAT table is missing Axis Value for 'wght' value
'100.0' [code: missing-axis-value-table]
FAIL STAT table is missing Axis Value for 'wdth' value
'50.0' [code: missing-axis-value-table]
FAIL STAT table is missing Axis Value for 'wght' value
'200.0' [code: missing-axis-value-table]
…and so on for all instances. Also it gives another FAIL for:
Checking if STAT entries matches fvar and vice versa.
Rationale:
Check for inconsistencies in names and values between the fvar
instances and STAT table. Inconsistencies may cause issues in
apps like Adobe InDesign.
FAIL Compressed Thin: 'wdth' axis value '50.0' missing in
STAT table. [code: missing-fvar-instance-axis-value]
FAIL Compressed Thin: 'wght' axis value '100.0' missing
in STAT table. [code: missing-fvar-instance-axis-value]
FAIL Compressed ExtraLight: 'wdth' axis value '50.0'
missing in STAT table. [code: missing-fvar-instance-axis-value]
FAIL Compressed ExtraLight: 'wght' axis value '200.0'
missing in STAT table. [code: missing-fvar-instance-axis-value]
FAIL Compressed Light: 'wdth' axis value '50.0' missing
in STAT table. [code: missing-fvar-instance-axis-value]
FAIL Compressed Light: 'wght' axis value '300.0' missing
in STAT table. [code: missing-fvar-instance-axis-value]
FAIL Compressed: 'wdth' axis value '50.0' missing in STAT
table. [code: missing-fvar-instance-axis-value]
FAIL Compressed: 'wght' axis value '400.0' missing in
STAT table. [code: missing-fvar-instance-axis-value]
FAIL Compressed Medium: 'wdth' axis value '50.0' missing
in STAT table. [code: missing-fvar-instance-axis-value]
… It continues for all instances also.
How do I fix this?
Some of the problems I might need to fix. It is at the very top of my list.
I’ve hit this roadblock as well. Thanks for looking into it!
I had to import glyphs files to Fontlab to export VF that could pass validation. Such a nightmare 
Oh please God not that. I hope I won’t have to go down that road! Is there any chance we get an update with this fix soon @GeorgSeifert ? 
Is there a way to manually fix tihs at the moment?
I finally worked on this. And I think I improved it a bit. Can you send me some example file for testing?
awesome! sent you a file.
Some tips gathered for max compatibility with current implementations in third-party apps:
ital or slnt axis if upright and italic are in different files.@frankrolf I have an issue with some of the checks for an italic OTVAR:
FAIL 'Regular' instance has the same coordinates as the
default instance; its postScriptNameID should be 6, instead of 263.
[code: invalid-default-instance-postscript-nameid:263]
I assume this is the fvar.NamedInstance.subfamilyNameID for the instance at wght=400. CMIIW but this check is impossible to fulfil if you have a separate Italic file with a wght axis (like Example 5 on the STAT spec page).
subfamilyNameID: Italic (same as nameID 2 or 17)name IDs 1 and 16 must be the same as in the Roman, otherwise it will not be considered the same family. The tricky part is that I have found that nameID 25 must be unique per file, otherwise InDesign misbehaves. Hence, in an Italic file, the composed postscriptNameIDs will contain the Italic indicator before the dash, which makes it impossible to make postscriptNameID the same as nameID 6.
SourceSans3 also fails the tests:
<!-- name ID 1: Source Sans 3 VF-->
<!-- name ID 2: Italic -->
<!-- name ID 6: SourceSans3VF-Italic -->
<!-- name ID 304: SourceSans3Italic-Regular -->
<NamedInstance flags="0x0" postscriptNameID="304" subfamilyNameID="2">
<coord axis="wght" value="400.0"/>
</NamedInstance>
Update: had a type about subfamilyNameID, fixed it.
See the changes I made for SS4:
The issue is that “Roman” and “Regular” are different (therefore pass the FB test), while this distinction is impossible for the Italic slope.
In current projects, I am forcing the creation of a nameID17 by setting the VF style name to “Dummy” (which is different from “Italic”), and then post-process the file with fontTools, to insert the style name of the default instance.
(The “Dummy” workaround is not necessary for SS4, because that project has an intermediate master at the “Regular Italic” weight, therefore the default is “Italic”.)
It is not elegant, but it works.
More experimentation. So, an update:
Changing the fvar instance entry of the regular-weight instance ‘Italic’ from this:
<NamedInstance flags="0x0" postscriptNameID="304" subfamilyNameID="2">
… to this:
<NamedInstance flags="0x0" postscriptNameID="6" subfamilyNameID="2">
… seems to work in InDesign, including style linking through Cmd-Shift-B/I. However, it has a different postscriptName structure than all the other instances. So I am kind of weary about third-party app compatibility.
In the meantime, I realized that my “Dummy” workflow + post-processing was unnecessary.
The current setup looks like this:
designspace — ps name of default instance represents the whole family:
<instance familyname="Family Roman" postscriptfontname="FamilyVF-Roman" stylename="Light Condensed">
<instance familyname="Family Roman" postscriptfontname="FamilyRoman-LightSemiCn" stylename="Light SemiCondensed">
<instance familyname="Family Roman" postscriptfontname="FamilyRoman-Light" stylename="Light">
<instance familyname="Family Italic" postscriptfontname="FamilyVF-Italic" stylename="Light Condensed Italic">
<instance familyname="Family Italic" postscriptfontname="FamilyItalic-LightSemiCn" stylename="Light SemiCondensed Italic">
<instance familyname="Family Italic" postscriptfontname="FamilyItalic-Light" stylename="Light Italic">
FontMenuNameDB — style name == name of the default instance:
[FamilyVF-Roman]
f=Family VF
s=Light Condensed
[FamilyVF-Italic]
f=Family VF
s=Light Condensed Italic
voilà