GSoC 2020: SMuFL glyph name to index lookup

[Owen Lamb]

Hi all,

I do believe I've finally tracked down the place where lilypond glyph names
are turned into character codes: Open_type_font::name_to_index. I can add a
ternary operator here based on whether the Open_type_font is_smufl (a new
property that, in the future, should be detected and set when the font is
initialized), and hook it into a new function which returns the correct
code point based on the SMuFL specification.

Now, I could take a few different routes with this.

On one hand, I could replace every instance of the lilypond glyph naming
system (i.e. clefs.G) with the SMuFL one (i.e. gClef). This would mean
every user would need to learn the new vocabulary if they want to reference
glyphs in their scheme code. (There's also the question of what to do about
glyphs in LilyPond that don't have a counterpart in SMuFL, which I plan to
research anyway.)

On the other hand, I could keep the current LilyPond naming system,
hand-writing a dictionary that translates LilyPond names straight into
SMuFL code points. This would retain a bit of nonstandardness, which might
annoy future developers, with the benefit of keeping my changes largely
inconsequential to the seasoned user.

On the third hand (I suppose it's a three-handed monster, oh well), I could
write multiple lookup functions--one to map lilypond name to SMuFL-name,
and another to map SMuFL-name to code point. This would make updating to
new versions of SMuFL especially easy, and keep end user experience the
same, but the lookup time would be twice as long, making performance suffer.

So, the way I see it, I have to sacrifice either backwards-compatibility,
full standardization, or performance. What do you all think I should go
for? Is there something I missed?

Thanks,
Owen