GSoC 2020 update, July 11

[Owen Lamb]

Hi all!

This week, I forgot to make a plan, so my work was a bit all over the
place. However, I did make progress in a couple places, and now I have a
plan of action for next week.

First, I added support for ligatures in the .mf files. To do this, I
changed the syntax in fet_beginchar's smuflname (now smufldata) parameter.
LilyPond doesn't yet build the ligatures out of components--it only notices
that there are new optional characters and maps them to the correct
codepoint. I also plan on adding support for optional glyphs that are not
stylistic alternates or ligatures in the future.

With this new capability, I finished encoding Feta's clefs. I also encoded
the full dynamics section and a few other scattered glyphs.

I created a new function, convert_glyph_name, that converts a
lilypond.style.name to a smuflStyleName whenever possible, otherwise
leaving the string untouched. I also created a Scheme function wrapper for
it, so it can be called by the end-user. This helped me clean up the
name_to_index function in open-type-font.cc.

---
Around the middle of the week, I tried to figure out how to get the
Emmentaler fonts into an OpenType collection, but FontForge only has docs
for "TrueType Collections". Apparently, FontForge can make OpenType
Collections by setting a "cff" flag in font.generateTtc's arguments, but
trying that (and many variations on it) only yielded an error:

ValueError: Layer is out of range

And when I tried to specify layer="Fore" in the parameters, it segfaulted!
(I don't even know what a segfault is, only that it's short for
"segmentation fault"...) So I put that investigation on hold, saving the
changes I made to a local branch. I'll come back to it after more essential
work is done, I suppose.
---

The last part of the week, I added the glyphsWithAnchors object to
Emmentaler's metadata file, populated with coordinates for stem
attachment--wx and wy (and the new dwx and dwy for down-facing stems--more
on that in a sec). They're not yet in the right units (they should be in
staff spaces), but I wanted to make sure the numbers made it to LilyPond
first.

The biggest challenge I've come across so far is the fact that SMuFL
defines two different "anchors" for upward- and downward- facing stems in
an asymmetric notehead glyph. LilyPond has historically created two
versions of such a glyph, each with its own set of wx/wy values to dictate
stem placement in its own direction. This will have to be changed in order
to fit SMuFL's specs.

That said, I have made a plan for next week (or at least the first part of
the week--it depends how long it will all take):

   - Convert stemUpSE and stemDownNW to units of staff spaces, as they
   should be.
   - When a stem faces down, have LilyPond read from stemDownNW instead of
   flipping stemUpSE around.
   - Make sure defaults for the mf variables chardwx and chardwy are
   correctly calculated as reflections of charwx and charwy (see commit
   bcc889ad for my initial, untested attempt).
   - In metafont, merge noteheads in which the only difference is up/down
   stem attachment point, e.g. u1triangle and d1triangle, by explicitly
   defining the new chardwx and chardwy variables.
   - Allow Emmentaler to have plain old optional characters that aren't
   ligatures or stylistic alternates of standard SMuFL glyphs; also, allow a
   glyph to have multiple codepoints if necessary.

If you have any questions, suggestions, or dire warnings, let me know!
(Also, if you have FontForge expertise, I'd appreciate any help figuring
out why FontForge can't generate OTC's. At the moment it's not too big a
deal, though.)

--Owen