Re: GSoC 2020: SMuFL glyph name to index lookup

[Han-Wen Nienhuys]

On Thu, May 28, 2020 at 6:44 AM Werner LEMBERG <wl@gnu.org> wrote:
> 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.

it's not just a historical decision. LilyPond needs to make
programmatic choices about which glyphs to select, for example, which
flag to print on a note depends on the duration of a note and its stem
direction. Using names makes encoding that easier: we just look for
flags{"u" for up, "d" for down}{duration-log}. This why I think it
will be practical to keep a map of Feta names around even if the whole
font gets a SmuFL layout.
> > 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.

You could hand write it, but for 500 glyphs, it may be a bit of work.
I would look into the following route:

The feta/emmentaler fonts are generated with scripts under mf/ . You could

1) update the MF code to emit Smufl character codes together with the
glyphs (look at scripts/build/mf-to-table.py and
mf/feta-autometric.mf). You can dump the mapping from mf-to-table in a
format that Python can easily read/write. JSON is probably the
simplest choice.

2) update the gen-emmentaler.py script so it composes the emmentaler
font using the Smufl layout. Read the information generated in 1) to
help you.

3) use the information created in 1) to create a separate table
mapping feta/emmentaler name to Smufl character code. I would suggest
to dump the mapping as a .scm file that loads the name => number map
into a hash table. You can copy the .scm file into the scm/ directory,
as it won't be changing very often.

4) load the table into lilypond. Check out lily/lily-imports.cc to see
how to load data from Scheme

5) use the table in LilyPond. In Open_type_font, use the GUILE hash
table functions to do the name=>number lookup.

6) Do this for just a subclass of glyphs (eg. note heads). You can
have a fallback in 5) to use the old mechanism if the hash table
doesn't turn up a Smufl character code.

once you have done 1-6 and it seems to be working (no output
differences, but a debugger shows that you load character codes from
the hash table), expand this mechanism to other classes of glyphs, eg.
flags, clefs, scripts, etc. You can do this is in follow up changes,
so we don't have to do a big-bang conversion.

beyond making lilypond load glyphs through smufl, this scheme also has
the benefit of rearranging Emmentaler in Smufl layout, so it can be
used in other places.

-- 
Han-Wen Nienhuys - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen