-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement internal charactermapping.plist from UFO roadmap? #55
Comments
No, you can't store additional files other than the public ones inside a UFO package (unless in the data dir), or else other implementations may drop them. |
I mean construct a character mapping internally, not write it out. |
Oh, ok, sure then. |
basically, something similar to defcon's UnicodeData class which is exposed to the font as Ideally, read-only using an immutable MappingProxyType |
hm I don't like that UnicodeData class very much, actually. It maps from characters to multiple glyphs which is impossible and wrong, only occurs as result of |
Yes, it would bend v3 conventions to enforce one Unicode value per glyph name, but the spec allows that. |
It's one glyph per unicode value, not one unicode value per glyph. Multiple unicodes can map to the same glyph, not viceversa. |
Err, yeah. |
We can expose a Even the Layer object could have a |
this is basically ufo2ft.util.makeUnicodeToGlyphNameMapping |
The UFO roadmap mentions the charactermapping.plist, to unambigiously assign Unicode values to glyph names across all layers (UFO spec discussion: unified-font-object/ufo-spec#77). I wonder if it would be worth implementing this internally before the UFO spec gets around to it, i.e. keep score internally as layers are loaded (with
public.default
taking precedence over all other layers). The spec already allows a library to do whatever when two same glyph names disagree on the Unicode value.The text was updated successfully, but these errors were encountered: