Expose mathGlyph filterRedundantPoints in RGlyph.fromMathGlyph() and .toMathGlyph()

[LettError]

This issue is part of a problem that spans fontMath.MathGlyph / fontParts.RGlyph / UFOProcessor. It should be possible to get data in and out of MathGlyph without the filterRedundantPoints filter. MathGlyph already has support for this.

History: by default MathGlyph adds on-point bcps to all straight segments on init, and filters the on-point bcps out on extraction. This was to reduce compatibility issues. Currently a lot of the work is done towards variable fonts and these are a lot stricter and the adding / filtering of bcps is just too invasive. The filtering even takes out points that were intended to be part of the outlines (see this UFOProcessor issue.)

MathGlyph has a flag to switch this filtering off. But I need to make sure it doesn't also add them at initialisation. We abstracted the way fontParts.RGlyph makes and gets MathGlyphs. So fontParts and its users can not get to those flags directly. And maintaining forked versions of mathGlyph / fontParts and ufoProcessor is a hassle.

Proposal: I would like to add a filterRedundantPoints or suitably renamed flag to toMathGlyph and fromMathGlyph. Default set to current behaviour, True. In an old (and stale) sketch I named this flag strict. Then I can add a similar flag to ufoProcessor and all its users too.

[benkiel]

Agree. Let me know if you want help with this.

[LettError]

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

[benkiel]

either, whatever is easiest for you

[LettError]

WIP 6f2c586
See also robotools/fontMath#232 (comment)

[LettError]

What to do with the calls that to toMathGlyph in fontParts.base.glyph, for instance add, sub and friends:

fontParts/Lib/fontParts/base/glyph.py

Line 1679 in 4a55d73

mathGlyph = self._toMathGlyph()

Can we tell what the intent is here? toMathGlyph will have strict=False as a default.
So how would I control the strictness in g1 + g2?

Maybe base.glyph needs its own strict flag?

[typemytype]

+1 for base.glyph strict flag which defaults False (the current implementation)

[benkiel]

@LettError Yes, I guess so, with the default behavior of False (shoot @typemytype just beat me to it)

[LettError]

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 be set as an attribute of the glyph, it would not necessary to be able to override it in toMathGlyph.

[lianghai]

Upstream updated: LettError/ufoProcessor#41