It seems to me that if you are going to use SMuFL fonts, you're either going to have to completely rewrite every lilypond glyph-name lookup (which should probably be phase 3 of the project) or you're going to have to have a lilypond-glyph-name-to-smufl-code-point lookup.
If I were doing it as part of a staged approach, I'd do the SMuFL code point lookup. Whether the lilypond-glyph-name-to-smufl-code-point lookup has an intermediate step of smufl-glyph-name probably doesn't matter to me, at least for now. It will be less efficient, but I'd be shocked if you could measure the difference in process time. Most of our time is spent doing layout, not looking up glyphs. It seems to me like you'll want to have a lilypond-glyph-name to smufl-glyph-name table created anyway, because you're going to have to make the changes to smufl-glyph-name in the code (or else hardcode the code points, but you seem to think they are possible to change, so we shouldn't do that). So I don't think the work to make the lilypond to smufl glyph name lookup is wasted work. But I think these are mostly stylistic decisions, and there's not much in the way of objective criteria that says one way or another is better. So do what you think best, IMO. Thanks, Carl On 5/27/20, 6:48 PM, "lilypond-devel on behalf of Owen Lamb" <lilypond-devel-bounces+carl.d.sorensen+digest=gmail....@gnu.org on behalf of owendl...@gmail.com> wrote: 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