when building cmap we should error/warn if multiple glyphs map to same unicode

[anthrotype]

Since we only build one cmap subtable, it's impossible for the same unicode codepoint to map to multiple different glyphs (of course the opposite is possible, multiple unicodes mapping to the same glyph).

However, this code:

https://github.com/googlei18n/ufo2ft/blob/7821e5f50afbc152eb30b4f5be3c2ea58867fca2/Lib/ufo2ft/outlineCompiler.py#L152-L165

does not check if uni is already in mapping but simply overwrites a pre-existing value. And it is iterating over the items of a dictionary (unsorted collection) so the last value that prevails may be different upon every run (because of the randomized hash seed).

The UFO spec doesn't say anything about this, so I must assume it doesn't disallow multiple glyphs sharing the same unicode value.
I don't know how common this situation is, but we need to handle this in a clear and deterministic way.

I think we should iterate in the order of the font.glyphOrder and only take the first one, then all the following we warn and skip.

Or we could be stricter and raise an error, but that's probably too harsh.

[moyogo]

The UFO spec doesn't say anything about this, so I must assume it doesn't disallow multiple glyphs sharing the same unicode value.

That’s not good but may happen. Keeping only one (first or last in font.glyphOrder) and warning is good enough. The user should sort that out.

[sladen]

Using the last (and warning the user that it is redefining/overriding probably makes more sense).

This is closer to what eg. a compiler does warning about (re-/defining twice), whilst still making it relatively easy to experiment with changing glyphs by copying-and-pasting the existing one and leaving it in place.

[behdad]

I like error (at least by default) better. This is not a warning. This is just bad input. Compiler comparison is not accurate. Compiler errs if the two definition are different.

[khaledhosny]

I agree with Behdad, multiple glyphs having same unicode values means some charters will be unsupported by the font and in a random way, so it is rather a bug in the input whether or not the UFO spec is silent about it.

It would be helpful, though, to collect all such errors in the font and report them (glyph names, unicode value) and not just error at the first occurrence of duplication.

[moyogo]

As long as the user gets a useful error, failing is fine.