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 <ol...@asu.edu
<mailto:ol...@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
