Add “seen pairs” list to UFO

[cjdunn]

As referenced here: https://twitter.com/typesupply/status/1420812198671224836?s=20

It would be helpful to know if I've looked at a kern pair and decided to keep it as zero, vs a pair that I haven't looked at yet.

This would also be helpful for cases when I interpolate kerning to use as a starting point for another source (master). I often interpolate/copy kerning as a starting point. If a seen pairs list was available, I would import the interpolated kerning and clear the list of seen pairs. Then as I go through each pair, the kerning extension (like Metrics Machine) could mark the pairs as seen.

I could also query this list at the end of the kerning process for all UFOs to see if I imported kerns into a UFO that I haven't seen yet, eg alternates that aren't in my kerning lists, or a chunk that I didn't go through yet.

Thank you for your consideration!

[benkiel]

Could this be a font level lib key?

[justvanrossum]

Yeah, lib.

[typesupply]

I'm thinking /data instead of lib since it's a potentially massive amount of data.

---

I suggested bringing the discussion here because, as CJ points out, it touches on a number of potential uses. A kerning interface, an interpolation script, a feature generator, etc. @LettError has requested storage in the font.lib of a list of pairs seen/approved in MetricsMachine so that, as best as I can recall, the pairs can be ignored later. The question for me is "What does seen mean?" In the context of MetricsMachine, it would mean "was looked at with a human eye" but that's a very limited meaning of the term.

We've touched on the idea of metadata for kerning pairs in the past so maybe this is more evidence of a need for that. Perhaps there could be a file located at /data/something.kerningdata.yamlOrJsonOrPlistOrDotDotDot that has a structure like this:

{
   pair : {
    key : data
   }
}

Basically, a lib for pairs. We could have the same key/value rules as lib and define public keys.

I don't think this should be fast tracked to be an official part of the spec. I think if there is a sense of need, we could think through the structure, document it as an unofficial thing and then see where it goes.

[cjdunn]

Thank you all for chiming in!

I'm going to try using a private lib for this for now: com.cjType.seenPairs . I added a few lines of code to do this using my RF extension MM2SpaceCenter, which is already paying attention to MetricsMachine.currentPairChanged and metricsMachine.GetCurrentPair()

I'm not sure if I'll need to store the parent group for each glyph in the pair if it exists. Or if I just figure that out later. For now I'm going to try storing that too in a separate lib: com.cjType.seenPairsWithGroups If it gets to be too much/slow I might reconsider. I do think it will be helpful to know when I've already seen a glyph from this group to know if I need an exception.

If anyone else wants to try the dev version of my extension, let me know. Or any other suggestions would be much appreciated, thanks!

[cjdunn]

@typesupply I'm not familiar with using /data, is there a way to read/write this already via fontparts? Or is this something for the future?

[benkiel]

I need to check, I'm not 100% that font parts reads data currently...

[typemytype]

fontParts has indeed not yet support for data see robotools/fontParts#439

[drj11]

Fonts with multiple collaborators / reviewers would presumably want to know who had looked at each kerning pair (or triple), and with what software.

The general principle is sound, but surely this is tool-specific lib stuff.

[LettError]

Lib stuff. But we could agree on a key and some sort of data structure.

[benkiel]

Yes, lib or data with a recommended key that is not part of spec. I should have closed this a while ago perhaps, but left it open for a informal recommendation on that.