It is a bit daft, really, even the documentation says that, if more than one code point encodes to the same glyph, querying the glyph for encoding with GlyphInfo("Encoding") (or the python interface) would randomly return either of them. This cause problems when re-encoding, as all except one of them is lost.
This is the 2nd problem with contributing to #3080 .
fontforge needs to provide direct scripting access to the forward and backward encoding vector.
You need that to manipulating the Adobe Source CJK / Google Noto CJK fonts properly. They have about 400 glyphs having multiple encoding. I can work around #3080 with an external script (either parsing ftdump -V with perl or using freetype-py with python) but I'd prefer not to.
It is a bit daft, really, even the documentation says that, if more than one code point encodes to the same glyph, querying the glyph for encoding with
GlyphInfo("Encoding")(or the python interface) would randomly return either of them. This cause problems when re-encoding, as all except one of them is lost.This is the 2nd problem with contributing to #3080 .
fontforge needs to provide direct scripting access to the forward and backward encoding vector.
You need that to manipulating the Adobe Source CJK / Google Noto CJK fonts properly. They have about 400 glyphs having multiple encoding. I can work around #3080 with an external script (either parsing
ftdump -Vwith perl or usingfreetype-pywith python) but I'd prefer not to.