lilypond-devel
[Top][All Lists]
Advanced

[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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]