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
