[tx] UFO read/write does not correctly handle double encoding

[punchcutter]

This test UFO contains glyphs that have multiple Unicode values. double-encoding.ufo.zip

A: 0041 and 55E0 (makes no sense, just a test) space: 0020 and 00A0

makeotf -f double-encoding.ufo -> The second value is lost. It should not be lost.

fontmake -u double-encoding.ufo -o otf -> Both values are correctly mapped.

[frankrolf]

makeotf’s default mode is not expected to do anything fancy – as far as I know, code point assignment only happens via a GlyphOrderAndAliasDB file (and only in release mode).

I think it’s time to move past this approach – use what’s in the UFO if there’s no external overrides, and use overrides if they’re present (the same would be applicable for many other data fields, like the version number).

[hatchzo]

When running makeotf, GlyphOrderAndAliasDB or cmap file can handle double encoding, but when tx -ufo option, there is no solution.