Re: SMuFL support: matching glyph names 1

[Owen Lamb]

Thanks for the suggestion, Abraham!

I'd already considered that route last summer (I probably should have 
mentioned before--this comes out of last year's Google Summer of Code), 
but I soon realized that it would be better to go by name.

SMuFL assigns a certain set of "recommended glyphs" to specific 
codepoints in the 0xE000 block, which is all well and good. But it also 
leaves 0xF400-0xF8FF as a catchall range for any extra glyphs SMuFL 
hasn't defined.

In order to keep track of those extra glyphs, which aren't guaranteed a 
stable codepoint, SMuFL requires that every extra glyph receive a name 
as well. This way, the same extra glyph can be identified across 
different fonts, even if their codepoints are different.

This means that, even if I were to assign every glyph by codepoint, I'd 
still also have to somehow specify the names of the extra glyphs. And 
since codepoint is no reliable indicator of identity for them, I figured 
it better to just define every glyph by its name (which is much more 
human-readable anyway) and then convert the name into a codepoint later 
on with a script.

A portion of my work on last year's Google Summer of Code project will 
make this conversion automatically. If the glyph's already a 
SMuFL-recommended glyph, off it goes to its own particular codepoint. If 
it's not, the glyph is placed in the next available spot in the 0xF400 
block and the name-codepoint association is stored in a SMuFL-compliant 
metadata file. Part of this is actually on hold as a draft merge request 
here: https://gitlab.com/lilypond/lilypond/-/merge_requests/701. (The 
metadata file generation, also from last summer, will hopefully come 
soon afterwards.)

And just in case it's not clear, this does not change the font's actual 
glyphname, which will remain as it is. It's just adding the extra SMuFL 
name to a couple fields in a metadata file that other SMuFL-compliant 
programs will recognize.

Owen

On 4/8/2021 4:02 PM, Abraham Lee wrote:
> This is great, Owen! One thing to keep in mind is that most 
> applications don’t access glyphs by name like LilyPond does. They 
> access by codepoint. So, in the vein of making Emmentaler SMuFL 
> compliant, codepoint will be more import than name. You may already be 
> taking this into account, but if not, aside from name mapping, you 
> ought to consider how the glyphs should be remapped to the SMuFL code 
> points. LilyPond doesn’t care if the glyphs even have a codepoint. 
> I’ve created numerous fonts with extra symbols that don’t have a 
> codepoint at all and it works wonderfully.
>
> That all said, I’d recommend this: use LilyPond’s recognized names, 
> use SMuFL code points. That may simplify the effort somewhat.
>
> Keep up the awesome work!
>
> Best,
> Abraham
>
> On Thu, Apr 8, 2021 at 3:00 PM Owen Lamb <olamb@asu.edu 
> <mailto:olamb@asu.edu>> wrote:
>
>     Hi all!
>
>     I've been working on matching Emmentaler's glyphs to SMuFL glyph
>     names,
>     and I'd appreciate some input on what I have so far.
>
>     Attached is a spreadsheet with my plans for naming the Clef, Time
>     Signature, Number, and Accidental glyph categories, as enumerated at
>     http://lilypond.org/doc/v2.23/Documentation/notation/the-emmentaler-font
>     <http://lilypond.org/doc/v2.23/Documentation/notation/the-emmentaler-font>.
>
>     The SMuFL names were taken from the Standard Music Font Layout
>     Specification, v1.4, found at https://w3c.github.io/smufl/latest
>     <https://w3c.github.io/smufl/latest>, under
>     the Glyph Tables heading.
>
>     I'm looking especially for input from folks who have experience
>     with the
>     Stockhausen accidental system, as well as whoever knows the
>     background
>     behind and usage of our accidentals.mirroredflat.backslash and
>     accidentals.flatflat.slash glyphs. Everyone's advice is welcome,
>     though!
>
>     If all goes well, this message will be the first of several like
>     it, as
>     I determine what to name every Emmentaler glyph under the SMuFL
>     system.
>
>     (As a reminder, this will /not/ override the current glyph naming
>     scheme; it /will /be providing an alternate way of locating glyphs
>     within LilyPond and give other programs a way to access Emmentaler's
>     glyphs via the SMuFL system.)
>
>     After a few days, if no one's made any objections, I'll move on to
>     the
>     next few glyph categories.
>
>     Regards,
>     Owen