[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GSoC 2020: OpenType support in FreeType
From: |
Werner LEMBERG |
Subject: |
Re: GSoC 2020: OpenType support in FreeType |
Date: |
Fri, 12 Jun 2020 08:15:06 +0200 (CEST) |
>> 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.
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.
>> 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?
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.
>> 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. [...]
>
> 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. [...]
Uh, oh, you are right, of course. So please forget my brain fart :-)
Werner