Re: GSoC 2020: SMuFL glyph name to index lookup

[Werner LEMBERG]

> 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