Re: GSoC 2020: Character lookup functions

[Werner LEMBERG]

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

This is correct.  I then believed that the primary source of
information is the OpenType font itself with its OpenType lookups and
features to access ligatures and alternate glyphs.

> But personally, I'm leaning towards option 3, since glyphnames.json
> provides an easy map from SMuFL name to charcode.

Meanwhile, you got the clarification from the SMuFL people that the
main source of information are the JSON files, and we essentially can
ignore OpenType stuff in the font itself.  This changes my point of
view, and I agree that it makes sense to implement option 3.

Irrespective of that, the current LilyPond glyph names should be
retained, either as the default, or as an backward compatibility
option – or both.


    Werner