ufo2ft.featureWriters lib key may be used to disable kern and/or mark feature generation

[anthrotype]

In https://github.com/docrepair-fonts/lunasima-fonts - sources/masters/Lunasima-Regular.ufo/lib.plist contains

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>com.github.googlei18n.ufo2ft.featureWriters</key>
    <array>
      <dict>
        <key>class</key>
        <string>KernFeatureWriter</string>
        <key>options</key>
        <dict>
          <key>mode</key>
          <string>skip</string>
        </dict>
      </dict>
    </array>

when this private lib key "com.github.googlei18n.ufo2ft.featureWriters" is present, ufo2ft uses this list instead of the built-in list of feature writers to generate things like kern or mark/mkmk features.

In this particular case, this has the effect of not building mark/mkmk features for Lunasima font, and as a result, no GPOS table is generated when this is built using fontmake (there isn't any kerning either...).

fontc instead ignores this and goes on to build mark/mkmk from the glyph anchors and a non-empty GPOS is built.

ttx_diff.py understandably reports a very bad score for Lunasima

Ideally ttx_diff could check for this lib key and tell fontc to only build mark or kern or neither accordingly.

[rsheeter]

I immediately wonder if this could be converted to a config.yaml entry. Auditing what it's used for might be interesting. If it's widely used fontc might need to support.

[cmyr]

I think it makes sense to handle this in fontc directly, checking for the presence of this key? Longer term we're going to need to move off of attributes that directly expose the implementation details of the existing compiler (e.g. we could just have keys for 'skip mark feature generation' or 'skip kern feature generation')