Erik van Blokland

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

What's better: a separate branch here, or a fork to my own account and then a PR? (are those even options)

WIP https://github.com/robotools/fontParts/commit/6f2c5868644409007c33ee2e909ca1bca46cb975 See also https://github.com/robotools/fontMath/issues/232#issuecomment-812554325

What to do with the calls that to `toMathGlyph` in `fontParts.base.glyph`, for instance __add__, __sub__ and friends: https://github.com/robotools/fontParts/blob/4a55d73d049e8122fb43fd32ce53b0dcbde10340/Lib/fontParts/base/glyph.py#L1679 Can we tell what the intent is here? toMathGlyph will have `strict=False`...

So that means adding a `def _get_strict(self):` and `def _set_strict(self, value):`, correct? Then perhaps it is too much to also add `def toMathGlyph(self, strict=None):` -- if the flag can already...

Should layer objects be able to response to `public.default` as well as `foreground` ?

I can't really tell from the image where the masters are.

* the desired instance is at the same location as the Thin master (Weight=26 Width=100) ? * what is the intended default location in this system?

In what model *do* these masters work? What makes it a varlib problem and not a problem of the assumptions of the design?

Well great! Export it from Glyphs, or have them publish their code.