GSoC 2020: Character lookup functions

[Owen Lamb]

Hi all,

I've started to dive into looking up glyph alternates, but quickly realized
I'll need to have a bigger plan in place first regarding what naming system
LP uses internally (the job that is currently done via
Font_metric::find_by_name). I figured I should probably update you guys
with my thoughts so far, so... here you go!

Last month we discussed this, so I guess now is the time to decide once and
for all. The options, as far as I can tell, are these:

   1. We could stick with the old-style glyphnames (e.g. "noteheads.s0").
   This would require minimal change to most of the code, since smufl_map.json
   already takes care of everything by mapping old-style names to charcodes.
   2. We could use charcodes (e.g. 0xE0A2), which, as Werner said, "will
   definitely make the code uglier (so we need *lots* of comments)".
   3. We could use SMuFL names (e.g. "noteheadWhole"). LilyPond can then
   use SMuFL's glyphnames.json (or something derived from it) to map SMuFL
   names to their charcodes.

Glyph alternates and ligatures complicate things further. The only link
between a font's glyphs and their stylistic alternates is via the base
glyph's SMuFL name (which maps to its alternates' SMuFL-style names and
codepoints). The same goes for ligatures. In order to use these tables,
we'll have to know the SMuFL name of any glyph we are looking for.

   - Option 1 would require a .scm hash table that maps old-style names to
   SMuFL names, so perhaps smufl_map.scm would be repurposed as
   glyphname_conversion.scm to do that. glyphnames.json could then provide the
   final step from SMuFL name to charcode.
   - For option 2, we'd either have to take glyphnames.json and create a
   reverse map from charcode to SMuFL name, or generate maps from the metadata
   file from codepoint to alternate codepoints (once again using the power of
   glyphnames.json).
   - Option 3 would make it a piece of cake--no conversion would be
   necessary.

Werner, I believe you said that in the long run option 2 would be the only
choice. But personally, I'm leaning towards option 3, since
glyphnames.json provides an easy map from SMuFL name to charcode. (A font's
metadata.json can provide a map of the same kind for the font-specific
F400+ area, ensuring no optional character is left out.) In addition, it
will mean that any SMuFL font's custom names for alternates and ligatures
and such will be immediately available to a user without hassle via
ly:font-get-glyph.

As a side note, option 1 could be viewed as a halfway step to option 3--and
even in option 3, a file like glyphname_conversion.scm wouldn't be bad to
have in case we want to keep legacy support for old-style names on the user
side as well.

Hope that all made sense. What do you all think?

Thanks,
Owen