[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GSoC 2020: SMuFL glyph name to index lookup
From: |
Carl Sorensen |
Subject: |
Re: GSoC 2020: SMuFL glyph name to index lookup |
Date: |
Thu, 28 May 2020 03:37:35 +0000 |
User-agent: |
Microsoft-MacOutlook/10.10.16.200509 |
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