Hi all, This week, I was able to encode the whole note (semibreve) glyph in its proper SMuFL-encoded spot in the PUA based on .mf log output.
I also got LilyPond to use a generated Scheme hash table to try to look up a glyph's SMuFL character code before falling back to the old way. This was particularly challenging, as I had to get my mind around Guile's many different notions of equality and find the right hash table lookup function to call. (For a while I didn't realize I was looking at docs for the wrong Guile version, too, which made things a bit frustrating.) At any rate, I now have a better handle on how Guile works in C++ and in general, and the lookup function works. I also had to rework open-type-font.cc's lookup functions. Now, name_to_index simply calls the new, more 'primitive' name_to_charcode and charcode_to_index methods in order to get the correct font index through SMuFL. (And in order for the ly:font-glyph-name-to-charcode Scheme function to use the new lookup for OpenType yet preserve lookup for Pango fonts, I made sure Pango-font also has a name_to_charcode function that simply calls name_to_index, then index_to_charcode, then just called name_to_charcode in ly:font-glyph-name-to-charcode.) I'd like to make sure, though: open-type-font.cc is *only* used for music fonts, and pango-font.cc for text fonts, correct? I don't want to mess anything up in the text encoding world. I added a couple LilyPond log messages that confirm whether a particular music glyph is looked up through the new method or the old one, so I can now see what I haven't encoded yet when I run LilyPond on a test file. PDF output remains unchanged, which is a good sign. Next, I've begun re-encoding other notehead glyphs, but of course I have run into difficulties rather quickly, since the old and new encodings hardly have a one-to-one mapping. SMuFL suggests using OTF stylistic alts on the same code point for distinguishing, e.g., double whole note (breve) glyphs with one or two lines on each side, but I've been having a bit of trouble finding how to do that in FontForge's Python docs. It will probably involve changing .mf's log output, too, adding support for an optional "." separator in the smuflcode string when Python reads the log, e.g. so that "E0A0.01" can be split into smufl_code and salt_code. The Scheme table also needs to support this, so I'll probably have to let the value of each key-value pair in the table optionally be a pair instead of a number to hold both codes. So that's where I am right now, and where I expect to go next week. If there's anything I missed/messed up, please let me know, as usual. Suggestions and advice are very welcome! Thanks, Owen
