Re: GSoC 2020 update, June 5

[Werner LEMBERG]

Hello Owen,


> 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.  [...]

Nice!

> 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.

Just a general remark: A glyph name to character code mapping function
only works if there is a guaranteed one-to-one relationship between
glyph names and character codes.  Normal text fonts, for example,
don't have this property; it is quite common that a font contains far
more glyphs than character codes.  Maybe this should be reflected in
comments for clarity.

> 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.

IIRC, you are correct.

> 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.

If difficulties arise, the FontForge people are usually quite helpful.

> 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.

Sounds sensible.

Congrats to your progress, which looks very promising!


    Werner