> 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.
I think there is a fundamental misunderstanding. Bravura is an OpenType font, and the only intended communication with such fonts is via character code values and *not* glyph names. It is a technical detail that LilyPond primarily communicates with OTF fonts via glyph names: this is necessary only because LilyPond natively emits PostScript code, which predates the invention of OpenType and thus doesn't use character codes. > 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). But the glyph name 'gClef' is internal to the Bravura font specification! It is just an aid for the font developer to have something mnemonic. Glyph names that are visible to clients (this is, being part of the font file itself) are normally of the form 'uniXXXX' or 'uXXXXX', with 'XXXX' and 'XXXXX' four-digit and five-digit uppercase hexadecimal values, respectively; this is recommended by the Adobe Glyph List Specification for New Fonts, obeyed by virtually all fonts today. https://github.com/adobe-type-tools/agl-aglfn/ If a font developer decides to use funny glyph names like 'MyVeryCheesyGeeClef' in the OpenType font: well, this *is* possible (but non-standard, of course), and today, with recent applications, such a font should work out of the box because only character codes are of importance. Instead, the route must be as follows. (1) Create a mapping from LilyPond glyph names to SMuFL character codes (which usually are in the Unicode's PUA). This is a static table since SMuFL has stabilized; if a new SMuFL version gets released, this table has to be updated within LilyPond. (2) Convert the character code resulting from (1) to the font's glyph index and proceed as usual. Only (1) is missing currently, AFAICS. It has to be investigated whether this mapping is one to one; I can imagine that some glyphs in LilyPond map to more than a single glyph in SMuFL and vice versa. > This would mean every user would need to learn the new vocabulary if > they want to reference glyphs in their scheme code. Definitely not :-) However, I can imagine that LilyPond provides an option to *also* allow Bravura glyph names (or maybe instead; I don't have an opinion here) for `\musicGlyph`. > (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.) This is the tricky part, I guess. > 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. Exactly. > This would retain a bit of nonstandardness, ... Not at all, IMHO. > ... which might annoy future developers, with the benefit of keeping > my changes largely inconsequential to the seasoned user. Again: Having an option to allow SMuFL glyph names is very useful, but it is not the right way to communicate with fonts following the SMuFL standard. > 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. Rather not. > So, the way I see it, I have to sacrifice either > backwards-compatibility, full standardization, or performance. Fortunately, there's nothing to sacrifice :-) Werner