Use STAT tables defined in UFO features instead of writing a generic STAT table

[kontur]

As described in this fontmake issue the variable font compilation in ufo2ft currently ignores any STAT tables present in UFO features and instead outputs the overly basic STAT table generated by fonttools.

As a very hacky simplification for these sample input files this results in the desired output with the STAT table as per the definitions in the features of those UFOs:

from defcon import Font
from ufo2ft import compileVariableTTF
from fontTools.designspaceLib import DesignSpaceDocument
from fontTools.feaLib.builder import addOpenTypeFeatures

ds = DesignSpaceDocument().fromfile("test/Test.designspace")

for src in ds.sources:
    src.font = Font(src.path)

vf = compileVariableTTF(ds, excludeVariationTables=["STAT"])
addOpenTypeFeatures(vf, "test/Test-CondensedBlack.ufo/features.fea", ("STAT",), True)
vf.save("VF-STAT.ttf")

compileVariableTTF by itself will trigger the generation of the generic STAT. There should be a metric for testing if features.fea contains STAT definitions and which if any UFO sources' STAT table to use.

I'm not sure if it would be better if fontTools itself had such an detection and generation-from-features functionality rather than strapping the STAT table into the file after the fact. E.g. in the build_many() method or the like.

Either way, the input UFOs containing STAT tables should result in those tables being used.

[anthrotype]

I'm not sure if it would be better if fontTools itself had such an detection

I think so, yes

[anthrotype]

The recommended way to build a full STAT table for VF using fontmake/ufo2ft is to make use of the designspace v5 axis labels (search for "STAT" in https://fonttools.readthedocs.io/en/latest/designspaceLib/xml.html -- the info is a bit scattered, but there should be examples).

But since feaLib can also build STAT from features.fea, if a user prefers to use that I agree with you we should at least not overwrite that with an incomplete STAT after the fact. This was an oversight on our part, thanks for bringing this up.

[kontur]

Ah, was not aware on the status of the STAT definitions in the designspace itself, that does seem preferable in the grand scheme of things.

[kontur]

As a sidenote... I don't think glyphsLib writes any such <labelname>s to designspaces, so a large portion of fontmake projects built from glyphs sources will not have any proper STAT data, no? This is how I originally ended up resorting to the STAT table defined in the features.

[anthrotype]

I think you're right. If you know how to set up a proper STAT table info from within Glyphs.app (besides STAT in features.fea, I mean) which can be used by glyphsLib to set the corresponding designspace v5 elements for varLib consumption, please let us know by filing an issue in glyphsLib ideally.

[anthrotype]

reminder to self to take a look at https://glyphsapp.com/learn/creating-a-variable-font which contains some info in the "Not really optional: STAT table" paragraph

[anthrotype]

will be fixed by https://github.com/fonttools/fonttools/pull/3024 once released