Re: GSoC 2020: OpenType support in FreeType

[Owen Lamb]

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