glyph.fromMathGlyph() confused by defcon.Color object
FontParts.Glyph.fromMathGlyph expects only tuples for guideline colors. But in practice I encounter Defcon color objects. These color objects are pretty much immutable, but they come from somewhere.
Is there a way that we can check for the type here in fontParts, in fromMathGlyph, and then extract the values? This would require fontParts to know something about defcon objects, I'm sure there are arguments against that.
What I would rather not have to do is to look at all the possible entry points where a guideline is added to a MathGlyph.
Alternatively, I propose this checks if it is a tuple, and if it is not, just discard the color info.
I think I know what is going on. The defcon Color object is a string with some special methods. The string base class allows it to be passed through ufoLib without any modifications since colors are stored as strings in UFO.
We should test that the incoming color value is an iterable and unpack it. This will eliminate the need to do an isinstance(tuple, list). Something like this:
if guideColor is None:
colorData = None
else:
r, g, b, a = guideColor
colorData = (r, g, b, a)
defcon's Color object has an __iter__ so it can be unpacked this way. This will raise an error if the color can't be unpacked into four elements. A bogus string of "abcd" could get in, but that will be caught by the color normalizer called downstream in appendGuideline.
This change will probably need to be applied to wherever font guides are extracted from a MathInfo.
Closed by #851