GSoC 2020 update, July 18

[Owen Lamb]

Hi all,

Well, I stuck to my plan this week! To recap:

In feta-autometric.mf, I made sure that the chardwx and chardwy variables
are correctly calculated as reflections of charwx and charwy if they aren't
explicitly defined in the character definition. There was a bit of
hullabaloo around strange operator precedence and undefined variables, but
it sorted itself out quickly enough.

The first large piece of work was getting LilyPond to understand up-stem
and down-stem attachment points separately. This meant I had to follow the
function call trail from where stems are calculated in stem.cc, through
note-head.cc, and finally to open-type-font.cc, where the information is
read from the font. I added a direction parameter to the necessary
functions and ensured that Lily no longer attempts to flip the up-stem
coordinates to get the down-stem ones.

(I also made a couple new scheme properties for a notehead grob:
stem-attachment-up and stem-attachment-down. At the moment, the old,
generic stem-attachment property simply calls for the -up or -down variant
depending on the grob's direction, but it may be wise to always make it
return stem-attachment-up, to preserve backwards compatibility.
Perhaps--although this is beyond my Scheme expertise--"setting"
stem-attachment should set stem-attachment-up, while setting
stem-attachment-down to an appropriate reflection as well? What do you all
think?)

The second large piece of work involved changing the units of the stemUpSE
and stemDownNW metadata properties to staff spaces instead of their
previous units (whatever is the default unit for metafont...), and making
LilyPond understand them as such. This one was definitely frustrating--I
had to remind myself what units functions were outputting by placing
temporary comments everywhere. I ended up giving some existing functions
descriptions as to what units they're in, so future visitors can see what's
going on at a glance.

(Poring over the code for this part, I came to the realization that I would
also have to change the bounding box parameters to staff spaces to keep the
calculations simple. Well, I was going to have to get around to that
eventually! LilyPond now reads from the metadata file for stem attachment
points and bounding box values, both in units of staff spaces.)

Finally, I consolidated some noteheads, such as u1triangle/d1triangle, into
a single glyph, i.e. s1triangle, by explicitly defining chardwx and chardwy
as needed. (I couldn't do this for every glyph, of course, as some glyphs
actually change appearance when flipped. Only redundant noteheads, whose
only difference was their stem attachment points, were merged.) After that,
I encoded those glyphs, filling out the rest of the Aikin shape-note glyphs
while I was at it. There are a few issues around shape note glyph encoding,
but I'll mention those in another message.

Just today, I made a quick fix to metadata generation. Plain optional
characters, which are not stylistic alternates or ligatures, can now be
defined. In the same commit, I got rid of a couple annoying entries for a
glyph named "0" that shouldn't have been there... my bad!

The only thing I didn't do this week was allow a glyph to have multiple
SMuFL names--that is, multiple Unicode codepoints. I have yet to see a need
for it. If I do, I'll put it in.

Whew! This week was a tough one, but I learned a lot about LilyPond's
insides--and hopefully, with a few comments, made it a little easier for
future devs to make the same journey. Next week, my plan is as follows:

   - Finish encoding noteheads (Again, I'll be asking about this).
   - Migrate the rest of the contents of LILY, LILC, and LILZ, as needed,
   to SMuFL metadata.json.
   - Have LilyPond read properties from metadata.json whenever it would
   usually read them from one of the old tables.
   - Convert these properties to the appropriate units and read them as
   such.
   - Remove the old tables.

My hope is that by the end of next week, we'll be able to use Bravura as a
drop-in replacement for Emmentaler without throwing any errors--even if its
glyphs won't be scaled correctly quite yet.

Any questions, comments, or concerns would be appreciated!

Thanks,
Owen