GSoC 2020 update, June 5

[Owen Lamb]

Hi all,

This week, I was able to encode the whole note (semibreve) glyph in its
proper SMuFL-encoded spot in the PUA based on .mf log output.

I also got LilyPond to use a generated Scheme hash table to try to look up
a glyph's SMuFL character code before falling back to the old way. This was
particularly challenging, as I had to get my mind around Guile's many
different notions of equality and find the right hash table lookup function
to call. (For a while I didn't realize I was looking at docs for the wrong
Guile version, too, which made things a bit frustrating.) At any rate, I
now have a better handle on how Guile works in C++ and in general, and the
lookup function works.

I also had to rework open-type-font.cc's lookup functions. Now,
name_to_index simply calls the new, more 'primitive' name_to_charcode and
charcode_to_index methods in order to get the correct font index through
SMuFL. (And in order for the ly:font-glyph-name-to-charcode Scheme function
to use the new lookup for OpenType yet preserve lookup for Pango fonts, I
made sure Pango-font also has a name_to_charcode function that simply calls
name_to_index, then index_to_charcode, then just called name_to_charcode in
ly:font-glyph-name-to-charcode.) I'd like to make sure, though:
open-type-font.cc is *only* used for music fonts, and pango-font.cc for
text fonts, correct? I don't want to mess anything up in the text encoding
world.

I added a couple LilyPond log messages that confirm whether a particular
music glyph is looked up through the new method or the old one, so I can
now see what I haven't encoded yet when I run LilyPond on a test file. PDF
output remains unchanged, which is a good sign.

Next, I've begun re-encoding other notehead glyphs, but of course I have
run into difficulties rather quickly, since the old and new encodings
hardly have a one-to-one mapping. SMuFL suggests using OTF stylistic alts
on the same code point for distinguishing, e.g., double whole note (breve)
glyphs with one or two lines on each side, but I've been having a bit of
trouble finding how to do that in FontForge's Python docs.

It will probably involve changing .mf's log output, too, adding support for
an optional "." separator in the smuflcode string when Python reads the
log, e.g. so that "E0A0.01" can be split into smufl_code and salt_code. The
Scheme table also needs to support this, so I'll probably have to let the
value of each key-value pair in the table optionally be a pair instead of a
number to hold both codes.

So that's where I am right now, and where I expect to go next week. If
there's anything I missed/messed up, please let me know, as usual.
Suggestions and advice are very welcome!

Thanks,
Owen