No GPOS for Oswald

[rsheeter]

As noted on #306, we aren't producing a GPOS for Oswald at all.

[anthrotype]

that's because there are no handwritten GPOS features in Oswald, only auto-generated ones (kern from higher level kerning dictionaries, possibly also mark + mkmk from glyph anchors), the stuff that ufo2ft featureWriters take care of.
We need to start thinking how to go about implementing these in fontc.
To be faithful to our 'variable-first' approach, instead of compiling one GPOS for each master and merge those at the end (as it's done currently in fontmake/ufo2ft/fonttools) we should generate features in variable syntax and build those as such (see googlefonts/ufo2ft#635).
fea-rs will need to support variable FEA syntax (cmyr/fea-rs#131) for this.

[rsheeter]

Taking notes in https://docs.google.com/document/d/1xsFkaa_G-wdhGW4I5zL4HoQw71LAt698kRXCwoq7hdE/edit

[rsheeter]

@simoncozens notes https://github.com/simoncozens/ds2varlayout is likely sufficient for Oswald, though not for the entire GF collection.

[rsheeter]

@anthrotype notes that the autogenerated parts of fea generation are to be found in ufo2ft.featureCompiler, which runs a series of so-called featureWriters (defined in ufo2ft.featureWriters) on each master font; these generate FEA for kern (kernFeatureWriter), mark, mkmk (markFeatureWriter), which gets appended or inserted in the hand-written FEA and then sent off for compilation to feaLib

[rsheeter]

See also googlefonts/ufo2ft#635 which gives a small example of variable kerning and some potentially informative related python to handle it.

[anthrotype]

As @simoncozens and @madig noted in googlefonts/ufo2ft#635, in order to make sure the variable-first kernFeatureWriter produces the same result (when compiled to GPOS) as the multiple-masters-then-varlib-merged one, the kerning dictionaries for each masters need to be "unioned" or "aligned" to properly take care of differing kerning "exceptions" in the various masters. In other words, kerns missing from some masters need to be "backfilled", not just with zeros but using the more "general" value available for the given glyph pair in each master (falling back to zeros if none), see:

googlefonts/ufo2ft#635 (comment)
googlefonts/ufo2ft#635 (comment)

Nikolaus has written a script to do that on a designspace+UFOs, see https://gist.github.com/madig/76567a9650de639bbff51ce010783790

We should incorporate this logic in when we convert kerning data from glyphs/UFO => IR. We cannot leave unspecified those missing kerning pairs, because our variable-first IR model for kerning (map of {KernPair: {Location: float}}) would then incorrectly imply that, if a pair doesn't specify a value for a given location, it should be interpolated at that location ("sparse kerning"), but the current font sources do not work like that. Master kerning dictionaries are not intended to be "sparse" in our current font source formats.

[rsheeter]

kerns missing from some masters need to be "backfilled", not just with zeros but using the more "general" value available for the given glyph pair in each master (falling back to zeros if none)

I think I'm going to merge #334 and do this in it's own PR.

[rsheeter]

Borrowing from a comment @anthrotype made so I don't forget: The UFO spec for kerning.plist explains this, see the paragraph about "Exceptions".
Also look at this algorithm for obtaining the effective kerning value for a given glyph+glyph combination taking into account exceptions and class membership:
https://unifiedfontobject.org/versions/ufo3/kerning.plist/#kerning-value-lookup-algorithm
The code lives in fontTools.ufoLib.kerning::lookupKerningValue

[rsheeter]

Reminder to self: we still need to port https://github.com/googlefonts/ufo2ft/blob/main/Lib/ufo2ft/featureWriters/markFeatureWriter.py

[cmyr]

Closing this, we are at least producing a vaguely reasonable GPOS table, and can move on to finer-grained issues.