Re: GSoC 2020: SMuFL glyph name to index lookup

[Carl Sorensen]

It seems to me that if you are going to use SMuFL fonts, you're either going to 
have to completely rewrite every lilypond glyph-name lookup (which should 
probably be phase 3 of the project) or you're going to have to have a 
lilypond-glyph-name-to-smufl-code-point lookup.

If I were doing it as part of a staged approach, I'd do the SMuFL code point 
lookup.

Whether the lilypond-glyph-name-to-smufl-code-point lookup has an intermediate 
step of smufl-glyph-name probably doesn't matter to me, at least for now.  It 
will be less efficient, but I'd be shocked if you could measure the difference 
in process time.  Most of our time is spent doing layout, not looking up glyphs.

It seems to me like you'll want to have a lilypond-glyph-name to 
smufl-glyph-name table created anyway, because you're going to have to make the 
changes to smufl-glyph-name in the code (or else hardcode the code points, but 
you seem to think they are possible to change, so we shouldn't do that).  So I 
don't think the work to make the lilypond to smufl glyph name lookup is wasted 
work.

But I think these are mostly stylistic decisions, and there's not much in the 
way of objective criteria that says one way or another is better.  So do what 
you think best, IMO.

Thanks,

Carl


 

On 5/27/20, 6:48 PM, "lilypond-devel on behalf of Owen Lamb" 
<lilypond-devel-bounces+carl.d.sorensen+digest=gmail.com@gnu.org on behalf of 
owendlamb@gmail.com> wrote:

Hi all,

I do believe I've finally tracked down the place where lilypond glyph names
are turned into character codes: Open_type_font::name_to_index. I can add a
ternary operator here based on whether the Open_type_font is_smufl (a new
property that, in the future, should be detected and set when the font is
initialized), and hook it into a new function which returns the correct
code point based on the SMuFL specification.

Now, I could take a few different routes with this.

On one hand, I could replace every instance of the lilypond glyph naming
system (i.e. clefs.G) with the SMuFL one (i.e. gClef). This would mean
every user would need to learn the new vocabulary if they want to reference
glyphs in their scheme code. (There's also the question of what to do about
glyphs in LilyPond that don't have a counterpart in SMuFL, which I plan to
research anyway.)

On the other hand, I could keep the current LilyPond naming system,
hand-writing a dictionary that translates LilyPond names straight into
SMuFL code points. This would retain a bit of nonstandardness, which might
annoy future developers, with the benefit of keeping my changes largely
inconsequential to the seasoned user.

On the third hand (I suppose it's a three-handed monster, oh well), I could
write multiple lookup functions--one to map lilypond name to SMuFL-name,
and another to map SMuFL-name to code point. This would make updating to
new versions of SMuFL especially easy, and keep end user experience the
same, but the lookup time would be twice as long, making performance suffer.

So, the way I see it, I have to sacrifice either backwards-compatibility,
full standardization, or performance. What do you all think I should go
for? Is there something I missed?

Thanks,
Owen