Re: GSoC 2020: OpenType support in FreeType

[Werner LEMBERG]

Hello Owen,


> I've given Emmentaler an OpenType lookup subtable for stylistic
> alternates, as the SMuFL specification suggests, and, as an
> experiment, I have successfully encoded the two types of double
> whole note (breve), one as a stylistic alternate of the other.
> However, LilyPond's current library for reading music fonts,
> FreeType, doesn't seem to support OpenType layout tables.

This is correct.  FreeType is a low-level library, and all additional
data necessary for LilyPond are read directly from the Emmentaler
font, using the SFNT structure (for tables like 'LILY') but not acting
in the OpenType sense.

> SMuFL's specification doesn't require a program to support OpenType
> features.  It states that a compliant font should also have some
> metadata JSON files that describe the same stylistic alternate and
> ligature information for such a program to read.
> 
> That said, it looks like I could go two ways.  Would you rather I
> switch FreeType for a font library with OpenType layout table
> support, or keep FreeType and have LilyPond take what it needs from
> a SMuFL font's metadata files?

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.

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.

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.


    Werner