Skip to content
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

Open
madig opened this issue Mar 10, 2020 · 10 comments
Open

Implement internal charactermapping.plist from UFO roadmap? #55

madig opened this issue Mar 10, 2020 · 10 comments

Comments

@madig
Copy link
Collaborator

madig commented Mar 10, 2020

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.

@anthrotype
Copy link
Member

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.
Better to move forward with that spec proposal.
We should also finish that PR that allows minor version to UFO, so we can start doing more incremental changes. fonttools/fonttools#1786

@madig
Copy link
Collaborator Author

madig commented Mar 10, 2020

I mean construct a character mapping internally, not write it out.

@anthrotype
Copy link
Member

Oh, ok, sure then.
If defcon has some method to get the character mapping, we should try to name it the same.

@anthrotype
Copy link
Member

basically, something similar to defcon's UnicodeData class
https://github.com/robotools/defcon/blob/master/Lib/defcon/objects/uniData.py

which is exposed to the font as Font.unicodeData property

Ideally, read-only using an immutable MappingProxyType

@anthrotype
Copy link
Member

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 unicode element currently belonging to the GLIF and thus the possibility that multiple GLIFs map to the same unicode (impossible in a valid font's cmap).
It should map each character to a single glyph, not list of glyphs.
And we should also think how to expose unicode variation selectors (unified-font-object/ufo-spec#79).

@madig
Copy link
Collaborator Author

madig commented Apr 2, 2020

Yes, it would bend v3 conventions to enforce one Unicode value per glyph name, but the spec allows that.

@anthrotype
Copy link
Member

anthrotype commented Apr 2, 2020

It's one glyph per unicode value, not one unicode value per glyph. Multiple unicodes can map to the same glyph, not viceversa.

@madig
Copy link
Collaborator Author

madig commented Apr 2, 2020

Err, yeah.

@anthrotype
Copy link
Member

We can expose a Font.getCharacterMapping() method that maps unicode (int) to glyph name (str) -- not a list of str (for the reasons I explained above). We can actually raise an error if there are conflicting mappings among the glyphs' unicodes (i.e. the same unicode mapped to different glyphs).

Even the Layer object could have a getCharacterMapping() since the unicodes are stored in each Glyph (which is what we want to get rid of..). But let's not do that. Font.getCharacterMapping() is enough, and will return the mapping for the default layer only.

@anthrotype
Copy link
Member

this is basically ufo2ft.util.makeUnicodeToGlyphNameMapping

https://github.com/googlefonts/ufo2ft/blob/66510c8128f9a447617c8c4d6d5871ef4577f74f/Lib/ufo2ft/util.py#L184-L206

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants