Hi all, Apologies for the lateness of this update. Last week was mostly research into stylistic alternates and how to support OpenType features in a SMuFL font, so not much was done in the way of code changes aside from creating a proof-of-concept stylistic alternate mapping.
It appears that the HarfBuzz library, already a LilyPond dependence thanks to Pango, can read an OT font's table of features. I sent a help request to the HarfBuzz mailing list, but it appears not to have gone through yet, since I'm not a member of the list. Now that the weekend's over and my message still hasn't appeared on the HarfBuzz archive, I've joined the list and sent the message again. Rather late in the week, I also came to the realization that, in order to support *any* SMuFL font's optional features, I'll also have to read its metadata JSON file if it has one, before defaulting to its OpenType features if it doesn't. (Thanks, Werner, for guiding me through that business!) So, my game plan for this week is as follows: while I correspond with HarfBuzz, I will generate a JSON file for Emmentaler. Then, I will have open-type-font.cc try to load a font's JSON file, and if that fails its GSUB table, into some sort of Scheme object (perhaps an alist?), which can then be read (or written--who knows if a user might want to mess with font metadata!) by LilyPond. I will probably need to create another font-specific Scheme alist so that specific font features, such as ligatures, alternates, or style sets, can be turned on or off at any point, telling HarfBuzz (or whatever glyph-replacing method we go with) which of them to use at any given moment. (A SMuFL font's metadata file also includes settings such as staff line thickness, etc. for drawing primitives in their correct proportions, so I'll eventually need to make LilyPond respect those as well. But one step at a time!) Once again, if you have any worries/suggestions, please let me know. I plan to send my next update on time, on Friday. Thanks, Owen