Re: GSoC 2020: OpenType support in FreeType

[Werner LEMBERG]

>> Unfortunately, the documentation of HarfBuzz is very terse.  I've
>> just checked
>> 
>>    https://harfbuzz.github.io
>> 
>>  and couldn't find out how to easily get a list of glyphs with its
>>  stylistic alternates.  Fortunately, the people on the HarfBuzz
>>  mailing list are willing to help.
> 
> I just sent out a message to the list, so we'll see where that goes.

Did you?  I can't see your message in the archive at

  https://lists.freedesktop.org/archives/harfbuzz/

Ah, you probably haven't subscribed to the list...  While not strictly
necessary, it would make communication quicker, since your e-mails
must be approved otherwise.

> One other thing that might throw a wrench through everything--I took
> a look at the one other freely available SMuFL font, Petaluma, and
> found that it has no OpenType layout tables whatsoever, despite
> having ligatures and alternates defined in its JSON metadata file
> (which, it turns out, is 'recommended,' not required).  It seems
> that if we want to support any font's alternate features out of the
> box, we'll probably have to look at its JSON file in order to
> confirm we haven't missed anything.  Perhaps the W3C Music Notation
> Community Group mailing list would be a good place to ask about
> whether it would be reasonable to assume one method or the other
> might be more 'complete' in general?  Or else, we could just attempt
> to support both...

Indeed, looking ath SMuFL specification again, we probably have to
support both the JSON metadata and the information embedded in the
OpenType font.  If the former is present, the latter is ignored.

Something else: it probably makes sense to eventually make Emmentaler
an OpenType Collection (OTC), containing one subfont for notation
purposes and the other one for text.


    Werner