Re: GSoC 2020: SMuFL glyph name to index lookup

[Werner LEMBERG]

>> 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