GSoC 2020 update, June 19

[Owen Lamb]

Hi all! Here with another weekly update.

This week, I corresponded with Daniel Spreadbury on the W3C Music Notation
Community Group public email list and Behdad Esfahbod on the HarfBuzz
mailing list, and received some clarifications on how to continue. It looks
like we won't need to add OpenType support! Instead, we only have to take
information from a SMuFL font's metadata.json.

To that end, I made some metadata files, one for each of Emmentaler's
design sizes. I then wrestled with the makefile docs until I got symbolic
links to those files to show up in the build/out/fonts/otf/ directory. It
seems to work, but I'd appreciate it if some more experienced eyes could
look it over to make sure I did it right:
https://gitlab.com/lilypond/lilypond/-/commit/fe125c4606dd275ea60db7ddd3e646cbe80dce68

(As for actually reading the metadata, I'm on the lookout for a good C++ or
Scheme library for parsing JSON. I've started that discussion in another
thread.)

I also started mapping out a few more categories of glyphs while I had the
time. Some categories were rather easy (especially rests), while others
(such as accordion) will need revisiting in more detail. I'm currently
keeping track of what categories still need work, etc. At any rate, I can
now compile a simple LilyPond score completely using the new glyph lookup
system!

Another thing I have been considering is how to package the Emmentaler
font. Daniel Spreadbury said that it would be feasible to make both
variants of Emmentaler (music and text, as per SMuFL specs) parts of an
OpenType Collection, as Werner suggested, but that does not include all the
design size variants Emmentaler already has. If it were possible to package
all of these together in a single OTC (I'd just have to figure out a good
way to organize them; perhaps FontForge's font.design_size property could
be used?), that may reduce file clutter as well, causing less hassle moving
the whole font family around. However, I'm not sure whether that will work,
since, as far as I can tell, each design size will need its own metadata
file due to their different line thicknesses. Right now, I'm
leaning towards just giving each design size a separate OTC with its two
SMuFL-mandated variations, but I'd appreciate other opinions in case
there's a better option.

It turns out that alternate glyphs need names, too. The JSON metadata file
requires every stylistic alternate to have a name, preferably in keeping
with the SMuFL-style naming scheme. Right now, the metadata files I've
generated simply use the glyph's Lily-style glyph names, for both the base
glyphs and their alternates. That will have to change. I'll probably go
back to the .mf files and extend the smufl_code variable further, allowing
alternates' names to be specified when necessary and placed in the metadata
file. (The base glyph names can be easily determined by using
SMuFL's name-to-unicode JSON map, so no worries there.)

I hope I didn't miss anything, but if I did, I'll let you know. In the
meantime, everyone have a great weekend!

--Owen