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
