Re: GSoC 2020: OpenType support in FreeType

[Owen Lamb]

Hi Werner,

I can help here.  Extracting lookup data for a single feature table in

an OpenType font is really just jumping from one font offset to
> another.  However, I agree that it is better to use a higher-level
> approach if available.
>

That would be fantastic! Hopefully HarfBuzz will fit our needs, but if not,
I'd appreciate the help.

Yes, it is.  Since Pango today always depends on HarfBuzz, we actually
> don't have a new dependency.  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.


> Uh, oh, you are right, of course.  So please forget my brain fart :-)
>

Forgotten. No worries! :)

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...

--Owen