Hi Werner, It should be straightforward to set up a fully functional OpenType
table for stylistic alternatives, as you've started already – the > 'salt' feature in a 'GSUB' table, I guess. LilyPond then extracts and > parses this table directly (similar to 'LILY'). This should be rather > easy to implement. > Hmm... I fail to see how this would be easy to implement. Currently, LilyPond interprets a SFNT table as a string and converts it to Scheme through the load_scheme_table function. I don't know how the GSUB table is encoded, so parsing it would probably require another library with OT support anyway. On the other hand, if there is a Pango library function that allows > easy access to stylistic alternatives, it might be easier to use it. > Pango's reference says that its functions for OT features are deprecated and have been superseded by the HarfBuzz library. HarfBuzz appears to be licensed mostly under the "Old MIT license" (with a small portion of of standard MIT). Is that a viable option, legally/practically? A third possibility is to add a Scheme code table (similar to 'LILY' > and friends) in addition to a 'GSUB' OpenType table that can be > directly digested by LilyPond. It's a bit redundant, but probably a > very simple solution since parsing is much simpler. > I'm not sure this will work. By the end of this summer, LilyPond should be able to read any SMuFL font as-is, including its stylistic alternates and other such features. Adding another Scheme table would allow LilyPond to read Emmentaler's alternates correctly, but not any other fonts' alternates or other features. That's why I figured parsing a SMuFL font's JSON metadata file would be a better universal solution if using OT features wasn't an option. (I'll have to generate the metadata anyway, if Emmentaler is going to be SMuFL-compliant.) Thanks, Owen
