>> It is a technical detail that LilyPond primarily communicates with >> OTF fonts via glyph names: this is necessary only because LilyPond >> natively emits PostScript code, which predates the invention of >> OpenType and thus doesn't use character codes. > > it's not just a historical decision. LilyPond needs to make > programmatic choices about which glyphs to select, for example, > which flag to print on a note depends on the duration of a note and > its stem direction. Using names makes encoding that easier: we just > look for flags{"u" for up, "d" for down}{duration-log}. This why I > think it will be practical to keep a map of Feta names around even > if the whole font gets a SmuFL layout.
I agree. However, I think the right solution is to make LilyPond use SMuFL character codes internally. This will definitely make the code uglier (so we need *lots* of comments), but I don't see an alternative to that in the long end. Accessing glyphs with LilyPond's glyph names would be an add-on. Using glyph names as shown in the SMuFL specification would be another add-on. > once you have done 1-6 and it seems to be working (no output > differences, but a debugger shows that you load character codes from > the hash table), expand this mechanism to other classes of glyphs, > eg. flags, clefs, scripts, etc. You can do this is in follow up > changes, so we don't have to do a big-bang conversion. This is an excellent suggestion. > beyond making lilypond load glyphs through smufl, this scheme also has > the benefit of rearranging Emmentaler in Smufl layout, so it can be > used in other places. Yes. Werner