SMuFL Bravura

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

SMuFL Bravura

Andrew Bernard
What is the current state of the art in using SMuFL fonts with lilypond 2.19.83? The blog posts I read referred to openlilylib modules to enable it, but with many references to issues such as subtle sizing problems etc etc. Is this ready for pro. use yet? Will it ever be, or are the incompatibilities in font technology a limitation?

To the point, I want some various string mute symbols. Would it be better for me to look into adding glyphs to Emmentaler with metafont? How extensible is Emmentaler?

Andrew



_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: SMuFL Bravura

Valentin Villenave-3
On 3/31/19, Andrew Bernard <[hidden email]> wrote:
> To the point, I want some various string mute symbols. Would it be better
> for me to look into adding glyphs to Emmentaler with metafont? How
> extensible is Emmentaler?

Very extensible; quite a few new glyphs have been added recently.
That is, however, assuming you can master metafont syntax. Many have
given up, but you’ll be regarded as a hero if you do -- well, at least
by me :-)

Using SMuFL with LilyPond requires but a thin compatibility layer
(mainly because of different glyph name mapping); that’s what the
OpenLily thingamabob does and it should be rather useable even with
recent LilyPond builds. (I wish it wasn’t implemented in that way, but
that’s how things are for now.)

Otherwise, you may or may not be better off with simple postscript or
svg markups, e.g. http://lsr.di.unimi.it/LSR/Item?id=1085

Cheers,
V.

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: SMuFL Bravura

Andrew Bernard
Hi Valentin,

Thanks so much. Now to learn Metafont then. Shouldn't be too hard - I have been a programmer for more than forty years. [Despite that, I still cannot come to grips with the lilypond source, and all my lilypond questions all appear to be from a beginner. :-) ]

The immediate task is to add various violin string mute symbols. But it sounds like this is going to be a useful skill to have.

Andrew



On Mon, 1 Apr 2019 at 01:50, Valentin Villenave <[hidden email]> wrote:

Very extensible; quite a few new glyphs have been added recently.
That is, however, assuming you can master metafont syntax. Many have
given up, but you’ll be regarded as a hero if you do -- well, at least
by me :-)


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: SMuFL Bravura

edes

el 2019-04-01 a las 11:37 Andrew Bernard escribió:

> Thanks so much. Now to learn Metafont then. Shouldn't be too hard

unlike valentin, i admire you already even if you don't succeed. i don't
know what admire the most: the determination of the "now to learn
metafont", or the optimism of the "shouldn't be too hard". i'm sure all of
us are wishing you the best of luck.







--

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: SMuFL Bravura

David Wright
In reply to this post by Andrew Bernard
On Mon 01 Apr 2019 at 11:37:42 (+1100), Andrew Bernard wrote:
> Hi Valentin,
>
> Thanks so much. Now to learn Metafont then. Shouldn't be too hard - I have
> been a programmer for more than forty years. [Despite that, I still cannot
> come to grips with the lilypond source, and all my lilypond questions all
> appear to be from a beginner. :-) ]
>
> The immediate task is to add various violin string mute symbols. But it
> sounds like this is going to be a useful skill to have.

Don't miss the book at http://www.ctex.org/documents/shredder/src/mfbook.pdf
I assume that font production is much the same as here, though the way
in which fonts are then handled may well have changed a lot.

Cheers,
David.

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: SMuFL Bravura

Aaron Hill
In reply to this post by edes
On 2019-03-31 6:14 pm, edes wrote:

> el 2019-04-01 a las 11:37 Andrew Bernard escribió:
>
>> Thanks so much. Now to learn Metafont then. Shouldn't be too hard
>
> unlike valentin, i admire you already even if you don't succeed. i
> don't
> know what admire the most: the determination of the "now to learn
> metafont", or the optimism of the "shouldn't be too hard". i'm sure all
> of
> us are wishing you the best of luck.

I gave Metafont a casual, first glance a number of months ago.  It did
not seem that difficult, although I am sure it has its fair share of
idiosyncrasies that I simply have not yet encountered.

One of Metafont's strengths as a tool is that each glyph is described
programmatically.  Consider when you want to have a font with a variety
of weights.  Rather than author each weight independently, Metafont lets
you describe glyphs in general terms, where the target weight is simply
an input parameter.  This process is admittedly more abstract than just
drawing the outline of each glyph by hand; but it certainly becomes much
more productive in the long-run.

As folks might already know, Lilypond's font comes in specific versions
for different target point sizes as to maintain a more consistent look
and feel to the shapes.  If you were to simply scale up or scale down a
glyph, then details can become too rounded or too sharpened compared to
other details.  Here again is where Metafont helps.  The general outline
of a glyph is described in code where things like the size and shape of
the virtual pen can be controlled parametrically.

I am not sure how complex the various articulations are that Andrew
needs to add.  Assuming there is an existing glyph that is close but
needs some tweaking, it should be fairly straightforward to adapt
current code to the new glyph.


-- Aaron Hill

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: SMuFL Bravura

Johan Vromans
In reply to this post by Andrew Bernard
On Mon, 1 Apr 2019 11:37:42 +1100, Andrew Bernard
<[hidden email]> wrote:

> Now to learn Metafont then. Shouldn't be too hard -

As a retired TeXnician I have deep respect for TeX and MetaFont.
Nevertheless I think the right way now is to go for widely accepted
standards where possible.

So I'd rather see decent SMuFL integration than more home grown Emmentaler
extensions.

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: SMuFL Bravura

David Kastrup
In reply to this post by Aaron Hill
Aaron Hill <[hidden email]> writes:

> On 2019-03-31 6:14 pm, edes wrote:
>> el 2019-04-01 a las 11:37 Andrew Bernard escribió:
>>
>>> Thanks so much. Now to learn Metafont then. Shouldn't be too hard
>>
>> unlike valentin, i admire you already even if you don't succeed. i
>> don't
>> know what admire the most: the determination of the "now to learn
>> metafont", or the optimism of the "shouldn't be too hard". i'm sure
>> all of
>> us are wishing you the best of luck.
>
> I gave Metafont a casual, first glance a number of months ago.  It did
> not seem that difficult, although I am sure it has its fair share of
> idiosyncrasies that I simply have not yet encountered.
>
> One of Metafont's strengths as a tool is that each glyph is described
> programmatically.

More like analytically.  One of the idiosyncrasies of Metafont is that
you usually describe the relations of the curves with equations rather
than assignments and Metafont then solves the equations.  It does not
make a difference between

    x = 7

and

    7 = x

It does have assignments ( := ) which work by first eliminating the
variable on the left-hand side as well as it can from existing
equations, then detaching it and then creating a new equation.

Also its expression machinery is designed around describing paths by
tracing semi-elliptical pencil outlines along cubic B-spline paths.

> I am not sure how complex the various articulations are that Andrew
> needs to add.  Assuming there is an existing glyph that is close but
> needs some tweaking, it should be fairly straightforward to adapt
> current code to the new glyph.

Imitation is the best form of flattery, yes.

--
David Kastrup

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: SMuFL Bravura

Urs Liska-3
In reply to this post by Johan Vromans
Hi Andrew and Johan,

Am 01.04.19 um 08:59 schrieb Johan Vromans:

> On Mon, 1 Apr 2019 11:37:42 +1100, Andrew Bernard
> <[hidden email]> wrote:
>
>> Now to learn Metafont then. Shouldn't be too hard -
> As a retired TeXnician I have deep respect for TeX and MetaFont.
> Nevertheless I think the right way now is to go for widely accepted
> standards where possible.
>
> So I'd rather see decent SMuFL integration than more home grown Emmentaler
> extensions.


I wanted to join this discussion although my comments had already become
separate from the direction of the discussion, but your comment gives me
a good opportunity.

These are two separate discussions, and I think SMuFL integration is not
opposed to extending Emmentaler and to using the Metafont approach in
the first place.

As has been pointed out currently SMuFL fonts such as Bravura can only
be used with a compatibility layer and actually using the fonts in a
non-native way. When Bravura is only wanted for its font design there is
a working clone by Abraham that can be used.

SMuFL integration doesn't seem to be very high on our priority list, but
I think it is by now accepted that changing LilyPond's font handling to
be SMuFL compliant would be a good thing to have. That's why we even
have a GSoC project suggestion for it:
http://lilypond.org/google-summer-of-code.html#Adopt-the-SMuFL-music-font-encoding-standard.
Making LilyPond's font handling compatible to using SMuFL fonts would
not mean that Emmentaler can't still be created from Metafont sources.

Andrew: Maybe having a look at that project would also be an option for
you? (Considering that chances we'll have a student working on it
through GSoC are definitely below 50%) It might even be an opportunity
to get familiar with how things work ...

Urs


> _______________________________________________
> lilypond-user mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/lilypond-user

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: SMuFL Bravura

David Kastrup
In reply to this post by David Wright
David Wright <[hidden email]> writes:

> On Mon 01 Apr 2019 at 11:37:42 (+1100), Andrew Bernard wrote:
>> Hi Valentin,
>>
>> Thanks so much. Now to learn Metafont then. Shouldn't be too hard - I have
>> been a programmer for more than forty years. [Despite that, I still cannot
>> come to grips with the lilypond source, and all my lilypond questions all
>> appear to be from a beginner. :-) ]
>>
>> The immediate task is to add various violin string mute symbols. But it
>> sounds like this is going to be a useful skill to have.
>
> Don't miss the book at
> http://www.ctex.org/documents/shredder/src/mfbook.pdf

The METAFONT book is copyrighted, and distribution of the PDF certainly
is a violation of the copying permissions for its source code which has
been made available for educational permissions with the following
notice/code at the start:

% This manual is copyright (C) 1986 by the American Mathematical Society.
% All rights are reserved!
% The file is distributed only for people to see its examples of TeX input,
% not for use in the preparation of books like The METAFONTbook.
% Permission for any other use of this file must be obtained in writing
% from the copyright holder and also from the publisher (Addison-Wesley).
\let\MFmanual=\!
\loop\iftrue
  \errmessage{This manual is copyrighted and should not be TeXed}\repeat

I don't think you are doing people a favor by pointing them to PDF files
created in defiance of the license, discouraging the publisher from
being similarly helpful in future.

--
David Kastrup

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: SMuFL Bravura

Malte Meyn-3
In reply to this post by Johan Vromans


Am 01.04.19 um 08:59 schrieb Johan Vromans:

> On Mon, 1 Apr 2019 11:37:42 +1100, Andrew Bernard
> <[hidden email]> wrote:
>
>> Now to learn Metafont then. Shouldn't be too hard -
>
> As a retired TeXnician I have deep respect for TeX and MetaFont.
> Nevertheless I think the right way now is to go for widely accepted
> standards where possible.
>
> So I'd rather see decent SMuFL integration than more home grown Emmentaler
> extensions.

SMuFL integration and using Metafont for glyph creation don’t
contradict, do they? Of course we should concentrate on glyphs requested
by SMuFL instead of “home grown” symbols. But why not use Metafont for
that? And if someone misses a glyph in Emmentaler that is not in SMuFL
one should make an enhancement request
(https://github.com/w3c/smufl/issues or
https://lists.w3.org/Archives/Public/public-music-notation-contrib/)

Of course we would have to rename the Emmentaler glyphs and have a
script that puts them at the correct code points in the font. And we
would have to look at the specification
(https://w3c.github.io/smufl/gitbook/specification/) for glyph metrics,
ligatures etc. Probably when metrics change there have to be changes in
the LilyPond source code too …

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: SMuFL Bravura

Johan Vromans
On Mon, 1 Apr 2019 09:17:26 +0200, Malte Meyn <[hidden email]> wrote:

> SMuFL integration and using Metafont for glyph creation don’t
> contradict, do they?

They do, in so far that with limited resources you cannot do both.

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: SMuFL Bravura

David Wright
In reply to this post by David Kastrup
On Mon 01 Apr 2019 at 09:16:24 (+0200), David Kastrup wrote:

> David Wright <[hidden email]> writes:
> > On Mon 01 Apr 2019 at 11:37:42 (+1100), Andrew Bernard wrote:
> >> Hi Valentin,
> >>
> >> Thanks so much. Now to learn Metafont then. Shouldn't be too hard - I have
> >> been a programmer for more than forty years. [Despite that, I still cannot
> >> come to grips with the lilypond source, and all my lilypond questions all
> >> appear to be from a beginner. :-) ]
> >>
> >> The immediate task is to add various violin string mute symbols. But it
> >> sounds like this is going to be a useful skill to have.
> >
> > Don't miss the book at [deleted]
>
> The METAFONT book is copyrighted, and distribution of the PDF certainly
> is a violation of the copying permissions for its source code which has
> been made available for educational permissions with the following
> notice/code at the start:

I hadn't realised that this book hadn't been made available under the
GFDL, like a fair number of books of this vintage. I was also fooled
(appropriate date) by the site. CTEX ≢ CTAN.

> % This manual is copyright (C) 1986 by the American Mathematical Society.
> % All rights are reserved!
> % The file is distributed only for people to see its examples of TeX input,
> % not for use in the preparation of books like The METAFONTbook.
> % Permission for any other use of this file must be obtained in writing
> % from the copyright holder and also from the publisher (Addison-Wesley).
> \let\MFmanual=\!
> \loop\iftrue
>   \errmessage{This manual is copyrighted and should not be TeXed}\repeat
>
> I don't think you are doing people a favor by pointing them to PDF files
> created in defiance of the license, discouraging the publisher from
> being similarly helpful in future.

I hadn't read the source code itself from CTAN.

Cheers,
David.

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: SMuFL Bravura

Malte Meyn-3
In reply to this post by Johan Vromans


Am 01.04.19 um 12:01 schrieb Johan Vromans:
> On Mon, 1 Apr 2019 09:17:26 +0200, Malte Meyn <[hidden email]> wrote:
>
>> SMuFL integration and using Metafont for glyph creation don’t
>> contradict, do they?
>
> They do, in so far that with limited resources you cannot do both.

[sending on-list, sorry Johan for the double post]

What do you mean by “limited resources”? A lack of manpower? I don’t
think it’s a real problem:

“In order for a font to be considered SMuFL-compliant, it should
implement as many of the recommended characters as are appropriate for
the intended use of the font, at the specified code points. Fonts need
not implement every recommended character, and need not implement any
optional glyphs, in order to be considered SMuFL-compliant.” (SMuFL
specification
https://w3c.github.io/smufl/gitbook/about/recommended-chars-optional-glyphs.html)

I think that means that Emmentaler could be made SMuFL-compliant without
having to add any characters: The intended use of Emmentaler is to work
with LilyPond as it will have done before SMuFL-compliance. Of course,
once this is done, additions can be made. But there is no need of new
Metafont code for SMuFL-compliance so I don’t think we should abandon
Metafont.

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: SMuFL Bravura

Urs Liska-3


Am 1. April 2019 20:07:47 MESZ schrieb Malte Meyn <[hidden email]>:

>
>
>Am 01.04.19 um 12:01 schrieb Johan Vromans:
>> On Mon, 1 Apr 2019 09:17:26 +0200, Malte Meyn <[hidden email]>
>wrote:
>>
>>> SMuFL integration and using Metafont for glyph creation don’t
>>> contradict, do they?
>>
>> They do, in so far that with limited resources you cannot do both.
>
>[sending on-list, sorry Johan for the double post]
>
>What do you mean by “limited resources”? A lack of manpower? I don’t
>think it’s a real problem:
>
>“In order for a font to be considered SMuFL-compliant, it should
>implement as many of the recommended characters as are appropriate for
>the intended use of the font, at the specified code points. Fonts need
>not implement every recommended character, and need not implement any
>optional glyphs, in order to be considered SMuFL-compliant.” (SMuFL
>specification
>https://w3c.github.io/smufl/gitbook/about/recommended-chars-optional-glyphs.html)
>
>I think that means that Emmentaler could be made SMuFL-compliant
>without
>having to add any characters: The intended use of Emmentaler is to work
>
>with LilyPond as it will have done before SMuFL-compliance. Of course,
>once this is done, additions can be made. But there is no need of new
>Metafont code for SMuFL-compliance so I don’t think we should abandon
>Metafont.
>

I fully agree with all of that, but I think what Johan wanted to say is that we should *first* work towards DMuFL compliance before spending manpower on Emmentaler extensions.
Which I think is true and not. If there is someone willing to spend efforts adding stuff to Emmentaler that's a great thing and shouldn't be discouraged because we have even more pressing things to do.

Urs

>_______________________________________________
>lilypond-user mailing list
>[hidden email]
>https://lists.gnu.org/mailman/listinfo/lilypond-user

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: SMuFL Bravura

Malte Meyn-3


Am 01.04.19 um 21:12 schrieb Urs Liska:
> I fully agree with all of that, but I think what Johan wanted to say is that we should *first* work towards DMuFL compliance before spending manpower on Emmentaler extensions.
> Which I think is true and not. If there is someone willing to spend efforts adding stuff to Emmentaler that's a great thing and shouldn't be discouraged because we have even more pressing things to do.

That sounds reasonable. And maybe I should try to make some
contributions for SMuFL (renaming and rearranging glyphs should be not
too hard). But that probably should wait until the release of 2.20.0 and
2.21.0, shouldn’t it?

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: SMuFL Bravura

Urs Liska-3

Am 02.04.19 um 09:05 schrieb Malte Meyn:

>
>
> Am 01.04.19 um 21:12 schrieb Urs Liska:
>> I fully agree with all of that, but I think what Johan wanted to say
>> is that we should *first* work towards DMuFL compliance before
>> spending manpower on Emmentaler extensions.
>> Which I think is true and not. If there is someone willing to spend
>> efforts adding stuff to Emmentaler that's a great thing and shouldn't
>> be discouraged because we have even more pressing things to do.
>
> That sounds reasonable. And maybe I should try to make some
> contributions for SMuFL (renaming and rearranging glyphs should be not
> too hard).


I don't really know how that works internally. But since LilyPond calls
glyphs by name while SMuFL looks at code points (is that correct?) I can
imagine it should be quite straightforward to get to a point (as a first
step) where LilyPond doesn't notice the change while SMuFL-compliant
applications can find the glyphs where *they* expect them.

Maybe it is a good idea to go for that first, completely ignoring the
font metrics because (as far as I understand how it works) that will be
trickier, more involved and probably somewhat tedious.


> But that probably should wait until the release of 2.20.0 and 2.21.0,
> shouldn’t it?

I don't think so. Of course such a fundamental change doesn't belong in
2.20, but adding stuff to the development branch doesn't seem
problematic to me. If it should turn out that starting with these
changes imposes any risk of breaking stuff we could still work on a
branch for a longer time (and maybe merge that to 2.21 after a 2.20
release).

Urs


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: SMuFL Bravura

Malte Meyn-3


Am 02.04.19 um 09:34 schrieb Urs Liska:
>> But that probably should wait until the release of 2.20.0 and 2.21.0,
>> shouldn’t it?
>
> I don't think so. Of course such a fundamental change doesn't belong in
> 2.20, but adding stuff to the development branch doesn't seem
> problematic to me. If it should turn out that starting with these
> changes imposes any risk of breaking stuff we could still work on a
> branch for a longer time (and maybe merge that to 2.21 after a 2.20
> release).

An extra branch is a good idea. I thought of people who want to use the
new features introduced in 2.21.0 but not 2.20.0 (there probably will be
a lot of those), therefore I’d add changes to master only after the
release of 2.21.0 (i. e. 2.21.1 would be the earliest possible release
for big SMuFL changes).

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: SMuFL Bravura

Urs Liska-3

Am 02.04.19 um 09:48 schrieb Malte Meyn:

>
>
> Am 02.04.19 um 09:34 schrieb Urs Liska:
>>> But that probably should wait until the release of 2.20.0 and
>>> 2.21.0, shouldn’t it?
>>
>> I don't think so. Of course such a fundamental change doesn't belong
>> in 2.20, but adding stuff to the development branch doesn't seem
>> problematic to me. If it should turn out that starting with these
>> changes imposes any risk of breaking stuff we could still work on a
>> branch for a longer time (and maybe merge that to 2.21 after a 2.20
>> release).
>
> An extra branch is a good idea. I thought of people who want to use
> the new features introduced in 2.21.0 but not 2.20.0 (there probably
> will be a lot of those), therefore I’d add changes to master only
> after the release of 2.21.0 (i. e. 2.21.1 would be the earliest
> possible release for big SMuFL changes).


Ah that's why you asked. No, adding stuff to the development branch will
*not* go into 2.20 anymore, that has already been forked. For any new
commits to be included in 2.20 David Kastrup would have to manually pick
them (which would simply not be done in this case).

Urs


_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user
Reply | Threaded
Open this post in threaded view
|

Re: SMuFL Bravura

Freeman Gilmore
In reply to this post by Malte Meyn-3



On Tue, Apr 2, 2019 at 3:06 AM Malte Meyn <[hidden email]> wrote:


Am 01.04.19 um 21:12 schrieb Urs Liska:
> I fully agree with all of that, but I think what Johan wanted to say is that we should *first* work towards DMuFL compliance before spending manpower on Emmentaler extensions.
> Which I think is true and not. If there is someone willing to spend efforts adding stuff to Emmentaler that's a great thing and shouldn't be discouraged because we have even more pressing things to do.

That sounds reasonable. And maybe I should try to make some
contributions for SMuFL (renaming and rearranging glyphs should be not
too hard). But that probably should wait until the release of 2.20.0 and
2.21.0, shouldn’t it?

I have been following this; but I do not know the interests of LilyPond.    A code point is a name, changing the name defeats the purpose of SMuFL.    SMuFL is in it early stages with more sambals and alternates being added that would have to be rename as they come about.   It seems to me that the LilyPond name and the SMuFL codepoint  (name) could  be combined in some sort of OR statement allowing both.   

ƒg

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user

_______________________________________________
lilypond-user mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-user