While working on a font reorganization, and considering corresponding keyboard updates that would be needed, it occurred to me that the “notes” attribute on each letter could be leveraged to facilitate the keyboard update.
The keyman input sequence that generates the symbol could be added to the notes field, a python script could parse the font and spit out the notes to generate a keyboard file (kmn) easily. Perhaps not the most optimal or efficient keyboard, but at least one that is functional. Keyman keyboard data that preceded the “begin” section could even be added to one of the font overview fields.
This info may be lost in a TTF format, but would be preserved in a source format like UFO. Going a step further, maybe KMD could use the UFO file as a keyboard source format?
I plan to give the python approach a try. I’m wondering if something like this has been done before and what was learned from the experience if so?
I’m not sure how well this would work. I don’t know how well that translates to keyboards – there’s a lot of knowledge embedded in many keyboards which is about how graphemes are constructed, normalization, reordering, visual vs phonetic input ordering, valid and invalid combinations, etc, etc.
It may be a viable experiment for very simple keyboard / writing system pairs? I wish you luck on the journey
I’m doubtful that this would be workable. Keyboards generate character sequences, not glyphs, and fonts (both TTF and UFO) store information as glyphs. If you have a perfectly one-to-one correspondence between characters and glyphs (as is almost the case with Ethiopic) then you might get it to work, but that would be an anomaly.
Where you store the keyboard sequence in the font is also difficult to manage. The two places in a UFO would be in the individual glif lib or as a glyphname-keyed list in the the font-wide lib.plist.
Both of these places have no interface in font design apps for managing them so you would need to manage the data manually in a text editor. We find that when we have extra glyph-specific data like this it’s easiest to manage it in an external glyph_data.csv file and use it to update data in the font (if necessary).
IOW even if you could assume a one-to-one character-glyph relationship, it’s likely easiest to manage keyboard sequence data externally from the font, keyed to characters, not glyphs.
