Re: Accidentals' font

[Urs Liska]

Am Freitag, den 10.07.2020, 10:34 +0200 schrieb Jean-Julien Fleck:
> Hello Urs,
> 
> Le ven. 10 juil. 2020 à 09:03, Urs Liska  a
> écrit :
> > 
> > But I'd like to repeat that the fonts created by Abraham (including
> > 
> > Gonville) are at least partially available as free fonts, and they
> > 
> > already *can* be used in a regular LilyPond installation without
> > any
> > 
> > hassles.
> > 
> > 
> > 
> > All you need to do is copy (or better link) the font files in the
> > fonts
> > 
> > directory (Frescobaldi even offers a nice interface for handling
> > that
> > 
> > for arbitrary new LilyPond installations) and add some code to the
> > 
> > paper block of your document. 
> > 
> > If you use openLilyLib this is as easy as \useNotationFont
> > Gonville.
> > 
> > The notation-fonts package even provides (optional) default
> > stylesheets
> > 
> > for all supported fonts (to provide a good starting point regarding
> > 
> > e.g. line thicknesses).
> 
> Could you please give us a link that explains how to do that
> installation ?
> 
> 
> I've been searching (a bit) ever since the page 
> https://github.com/OpenLilyPondFonts appeared in this thread but
> couldn't find a tutorial to explain step by step what to do. I would
> have expected that such an explanation to be placed in the README.md
> file at the top of each font repository, at least pointing to a place
> explaining the generic way to do it but I couldn't find any.
> 
> Is there such a step-by-step tutorial and where can I find it ?

Unfortunately not comprehensively.
There's  https://github.com/openlilylib/oll-core/wikiwhich explains how
to obtain openLilyLib
  https://github.com/openlilylib/notation-fonts/gives a short overview
on how the notation-fonts package is used.
  
https://github.com/openlilylib/notation-fonts/tree/master/usage-examples/fontsincludes
several usage examples (along with compiled PDF files).
I'm not sure where installing additional fonts in LilyPond is
explained, but in a nutshell: you have to identify
the  /usr/share/lilypond/current/fonts/directory within a given
LilyPond installation, and drop the OTF and SVG font files in the
corresponding subdirectory (.woff files go into SVG).Best practice for
this is storing all your fonts in one central location and place links
into the LilyPond directory.
If you use a current Frescobaldi the tool Tools=>Document fonts
provides a convenient interface for manging fonts (installation and
creating the input code).
HTH
Urs
> Thanks,
> 
> --
> JJ Fleck
> Physique et Informatique
> PCSI1 Lycée Kléber

Re: Accidentals' font

[Jean Abou Samra]

Hi Jean-Julien,

Le 10/07/2020 à 10:34, Jean-Julien Fleck a écrit :

Hello Urs,


Le ven. 10 juil. 2020 à 09:03, Urs Liska > a écrit :



But I'd like to repeat that the fonts created by Abraham (including
Gonville) are at least partially available as free fonts, and they
already *can* be used in a regular LilyPond installation without any
hassles.

All you need to do is copy (or better link) the font files in the
fonts
directory (Frescobaldi even offers a nice interface for handling that
for arbitrary new LilyPond installations) and add some code to the
paper block of your document.

The manual procedure is described at 
http://lilypond.org/doc/v2.20/Documentation/notation/replacing-the-notation-font.en.html


I guess you can also just open the dedicated Frescobaldi interface and 
follow the steps.



If you use openLilyLib this is as easy as \useNotationFont Gonville.
The notation-fonts package even provides (optional) default
stylesheets
for all supported fonts (to provide a good starting point regarding
e.g. line thicknesses).


Could you please give us a link that explains how to do that 
installation ?


I've been searching (a bit) ever since the page 
https://github.com/OpenLilyPondFonts appeared in this thread but 
couldn't find a tutorial to explain step by step what to do. I would 
have expected that such an explanation to be placed in the README.md 
file at the top of each font repository, at least pointing to a place 
explaining the generic way to do it but I couldn't find any.


Is there such a step-by-step tutorial and where can I find it ?


What Urs describes is an openLilyLib package, so you want to get started 
with openLilyLib first. 
https://www.openlilylib.org/getstarted/install.html, perhaps?


Regards,
Jean Abou Samra

Re: Accidentals' font

[Jean-Julien Fleck]

Hello Urs,


Le ven. 10 juil. 2020 à 09:03, Urs Liska  a écrit :

>
> But I'd like to repeat that the fonts created by Abraham (including
> Gonville) are at least partially available as free fonts, and they
> already *can* be used in a regular LilyPond installation without any
> hassles.
>
> All you need to do is copy (or better link) the font files in the fonts
> directory (Frescobaldi even offers a nice interface for handling that
> for arbitrary new LilyPond installations) and add some code to the
> paper block of your document.
> If you use openLilyLib this is as easy as \useNotationFont Gonville.
> The notation-fonts package even provides (optional) default stylesheets
> for all supported fonts (to provide a good starting point regarding
> e.g. line thicknesses).
>

Could you please give us a link that explains how to do that installation ?

I've been searching (a bit) ever since the page
https://github.com/OpenLilyPondFonts appeared in this thread but couldn't
find a tutorial to explain step by step what to do. I would have expected
that such an explanation to be placed in the README.md file at the top of
each font repository, at least pointing to a place explaining the generic
way to do it but I couldn't find any.

Is there such a step-by-step tutorial and where can I find it ?

Thanks,

--
JJ Fleck
Physique et Informatique
PCSI1 Lycée Kléber

Re: Accidentals' font

[Urs Liska]

Am Donnerstag, den 09.07.2020, 21:40 +0200 schrieb Paolo Prete:
> On Thu, Jul 9, 2020 at 8:35 PM Jean Abou Samra 
> wrote:
> 
> > Le 08/07/2020 à 15:31, Paolo Prete a écrit :
> > 
> > 
> > 
> > On Wed, Jul 8, 2020 at 12:13 PM Jean Abou Samra  > >
> > wrote:
> > 
> > > I would like to emphasize that this is not at all simple. I agree
> > > that
> > > the technical part is reachable. Yet, this has consequences on
> > > the
> > > organization of the LilyPond ecosystem that have to be considered
> > > with care.
> > > 
> > > Fonts external to LilyPond also have development cycles that are
> > > different from LilyPond’s. If Gonville or other fonts were
> > > integrated as
> > > built-in options, we would end up receiving bug reports or
> > > feature requests
> > > from fellow users about fonts which we are incompetent about. It
> > > would
> > > force the authors of these fonts to follow LilyPond issues and
> > > make changes
> > > in parallel with Feta, for example, make it SMuFL-compliant by
> > > the end of
> > > the summer, which is very demanding. When the original author
> > > will not be
> > > available or no longer willing to support it, users will complain
> > > about the
> > > font not working and other LilyPond developers will need to fix
> > > it, and
> > > first learn its generation system, which is a custom one entirely
> > > different
> > > from Feta’s.
> > > 
> > 
> > Hello Jean,
> > 
> > I think the problem you emphasize is automatically solved with the
> > ./configure flag. Let me show a practical example.
> > ffMPEG has a native aac codec and a configure flag (--enable-
> > libfdk-aac)
> > which adds a third-party aac encoder (Fraunhofer FDK AAC).
> > 
> > Hi Paolo,
> > 
> > If I'm not mistaken, the use case for configure flags like
> > --enable-guilev2 is to influence compilation. By contrast, fonts
> > are loaded
> > dynamically at runtime. Hence, a configure flag would essentially
> > do
> > nothing but move a few files (except if it changed the default, but
> > we
> > don't want that).
> > 
> 
> Hi Jean,
> 
> I intended it exactly in the way you described. That flag would not
> influence compilation but only *linking*, preventing compatibility
> issues
> (mismatch of versions)
> 
> 
> > In fact, it's already possible and very simple to build LilyPond
> > with
> > Gonville support: just follow the usual build procedure, then copy
> > the
> > Gonville OTF files into
> > build/out/share/lilypond/current/fonts/otf/. That's
> > simple enough that I don't believe it deserves a special flag.
> > 
> 
> Yes, but this would make a *patched* build, and not a clean build.
> Note too
> that the flag should be more general than --with-gonville-font (for
> example, just an extemporary idea: --with-font=gonville,foobarfont
> etc.)
> 
> 
> 
> > Doing that, every maintainer of a *distro* (I highlight the word
> > *distro*,
> > and not the src one) can choose to create the binary with or
> > without third
> > party pieces.
> > Note that, for example, ffMPEG. There are some distros of ffMPEG
> > with
> > x264, and some distros without.
> > 
> > This nuance is not possible with LilyPond since, to my knowledge,
> > the vast
> > majority of users downloads binaries from lilypond.org.
> > 
> 
> This is true. But what if, in the future, someone wants to create,
> for
> example, a Linux Distro called LilyBuntu ? ;-)
> 
> 
> 
> > That said, I really think we ought to pause this discussion until
> > the
> > details of SMuFL support get clear.
> > 
> > 
> I agree. I pause it as well.
> 

But I'd like to repeat that the fonts created by Abraham (including
Gonville) are at least partially available as free fonts, and they
already *can* be used in a regular LilyPond installation without any
hassles.

All you need to do is copy (or better link) the font files in the fonts
directory (Frescobaldi even offers a nice interface for handling that
for arbitrary new LilyPond installations) and add some code to the
paper block of your document. 
If you use openLilyLib this is as easy as \useNotationFont Gonville.
The notation-fonts package even provides (optional) default stylesheets
for all supported fonts (to provide a good starting point regarding
e.g. line thicknesses).

So I really don't see the need for a patched compilation of LilyPond.
Urs

>  Best,
> P

Re: Accidentals' font

[Paolo Prete]

On Thu, Jul 9, 2020 at 8:35 PM Jean Abou Samra  wrote:

> Le 08/07/2020 à 15:31, Paolo Prete a écrit :
>
>
>
> On Wed, Jul 8, 2020 at 12:13 PM Jean Abou Samra 
> wrote:
>
>> I would like to emphasize that this is not at all simple. I agree that
>> the technical part is reachable. Yet, this has consequences on the
>> organization of the LilyPond ecosystem that have to be considered with care.
>>
>> Fonts external to LilyPond also have development cycles that are
>> different from LilyPond’s. If Gonville or other fonts were integrated as
>> built-in options, we would end up receiving bug reports or feature requests
>> from fellow users about fonts which we are incompetent about. It would
>> force the authors of these fonts to follow LilyPond issues and make changes
>> in parallel with Feta, for example, make it SMuFL-compliant by the end of
>> the summer, which is very demanding. When the original author will not be
>> available or no longer willing to support it, users will complain about the
>> font not working and other LilyPond developers will need to fix it, and
>> first learn its generation system, which is a custom one entirely different
>> from Feta’s.
>>
>
> Hello Jean,
>
> I think the problem you emphasize is automatically solved with the
> ./configure flag. Let me show a practical example.
> ffMPEG has a native aac codec and a configure flag (--enable-libfdk-aac)
> which adds a third-party aac encoder (Fraunhofer FDK AAC).
>
> Hi Paolo,
>
> If I'm not mistaken, the use case for configure flags like
> --enable-guilev2 is to influence compilation. By contrast, fonts are loaded
> dynamically at runtime. Hence, a configure flag would essentially do
> nothing but move a few files (except if it changed the default, but we
> don't want that).
>

Hi Jean,

I intended it exactly in the way you described. That flag would not
influence compilation but only *linking*, preventing compatibility issues
(mismatch of versions)


> In fact, it's already possible and very simple to build LilyPond with
> Gonville support: just follow the usual build procedure, then copy the
> Gonville OTF files into build/out/share/lilypond/current/fonts/otf/. That's
> simple enough that I don't believe it deserves a special flag.
>

Yes, but this would make a *patched* build, and not a clean build. Note too
that the flag should be more general than --with-gonville-font (for
example, just an extemporary idea: --with-font=gonville,foobarfont etc.)



>
> Doing that, every maintainer of a *distro* (I highlight the word *distro*,
> and not the src one) can choose to create the binary with or without third
> party pieces.
> Note that, for example, ffMPEG. There are some distros of ffMPEG with
> x264, and some distros without.
>
> This nuance is not possible with LilyPond since, to my knowledge, the vast
> majority of users downloads binaries from lilypond.org.
>

This is true. But what if, in the future, someone wants to create, for
example, a Linux Distro called LilyBuntu ? ;-)



> That said, I really think we ought to pause this discussion until the
> details of SMuFL support get clear.
>
>
I agree. I pause it as well.

 Best,
P

Re: Accidentals' font

[Jean Abou Samra]

Le 08/07/2020 à 15:31, Paolo Prete a écrit :



On Wed, Jul 8, 2020 at 12:13 PM Jean Abou Samra > wrote:


I would like to emphasize that this is not at all simple. I agree
that the technical part is reachable. Yet, this has consequences
on the organization of the LilyPond ecosystem that have to be
considered with care.

Fonts external to LilyPond also have development cycles that are
different from LilyPond’s. If Gonville or other fonts were
integrated as built-in options, we would end up receiving bug
reports or feature requests from fellow users about fonts which we
are incompetent about. It would force the authors of these fonts
to follow LilyPond issues and make changes in parallel with Feta,
for example, make it SMuFL-compliant by the end of the summer,
which is very demanding. When the original author will not be
available or no longer willing to support it, users will complain
about the font not working and other LilyPond developers will need
to fix it, and first learn its generation system, which is a
custom one entirely different from Feta’s.


Hello Jean,

I think the problem you emphasize is automatically solved with the 
./configure flag. Let me show a practical example.
ffMPEG has a native aac codec and a configure flag 
(--enable-libfdk-aac) which adds a third-party aac encoder (Fraunhofer 
FDK AAC).


Hi Paolo,

If I'm not mistaken, the use case for configure flags like 
--enable-guilev2 is to influence compilation. By contrast, fonts are 
loaded dynamically at runtime. Hence, a configure flag would essentially 
do nothing but move a few files (except if it changed the default, but 
we don't want that). In fact, it's already possible and very simple to 
build LilyPond with Gonville support: just follow the usual build 
procedure, then copy the Gonville OTF files into 
build/out/share/lilypond/current/fonts/otf/. That's simple enough that I 
don't believe it deserves a special flag.



Now, what does happen if

1) there are compatibility issues between versions and/or API  of the 
two softwares


or

2) the author of the third-party codec stops to develop it

...?

Well: in case of 1) the user can remove the flag. In case of 2) the 
ffMPEG src maintainer can remove the flag.
It's just a wrap/link, not a support for the feature. But this link 
makes the feature ready to be used.


Doing that, every maintainer of a *distro* (I highlight the word 
*distro*, and not the src one) can choose to create the binary with or 
without third party pieces.
Note that, for example, ffMPEG. There are some distros of ffMPEG with 
x264, and some distros without.


This nuance is not possible with LilyPond since, to my knowledge, the 
vast majority of users downloads binaries from lilypond.org. In the end, 
we decide to include or not to include more fonts in the installers 
produced by GUB, and as a consequence, the feature is supported by 
LilyPond or not. I do not see that this technical solution adresses the 
human problem, namely, what the LilyPond team accepts to maintain. 
(Perhaps a warning in the documentation could suffice; this would 
certainly need debate.)


That said, I really think we ought to pause this discussion until the 
details of SMuFL support get clear.


Kind regards,
Jean


Best,

P

Re: Accidentals' font

[Paolo Prete]

On Wed, Jul 8, 2020 at 12:13 PM Jean Abou Samra  wrote:


> t to press developers/maintainers to develop anything. My idea was,
> instead, to show how good it could be to use what I consider an
> *impressive* work *already done* by someone else. Just link it, do not
> develop anything.
>
>
> I would like to emphasize that this is not at all simple. I agree that the
> technical part is reachable. Yet, this has consequences on the organization
> of the LilyPond ecosystem that have to be considered with care.
>
> Fonts external to LilyPond also have development cycles that are different
> from LilyPond’s. If Gonville or other fonts were integrated as built-in
> options, we would end up receiving bug reports or feature requests from
> fellow users about fonts which we are incompetent about. It would force the
> authors of these fonts to follow LilyPond issues and make changes in
> parallel with Feta, for example, make it SMuFL-compliant by the end of the
> summer, which is very demanding. When the original author will not be
> available or no longer willing to support it, users will complain about the
> font not working and other LilyPond developers will need to fix it, and
> first learn its generation system, which is a custom one entirely different
> from Feta’s.
>

Hello Jean,

I think the problem you emphasize is automatically solved with the
./configure flag. Let me show a practical example.
ffMPEG has a native aac codec and a configure flag (--enable-libfdk-aac)
which adds a third-party aac encoder (Fraunhofer FDK AAC).
Now, what does happen if

1) there are compatibility issues between versions and/or API  of the two
softwares

or

2) the author of the third-party codec stops to develop it

...?

Well: in case of 1) the user can remove the flag. In case of 2) the ffMPEG
src maintainer can remove the flag.
It's just a wrap/link, not a support for the feature. But this link makes
the feature ready to be used.

Doing that, every maintainer of a *distro* (I highlight the word *distro*,
and not the src one) can choose to create the binary with or without third
party pieces.
Note that, for example, ffMPEG. There are some distros of ffMPEG with x264,
and some distros without.

Best,

P

Re: Accidentals' font

[Jean Abou Samra]

Hi Paolo,

Le 08/07/2020 à 02:07, Paolo Prete a écrit :

I have to apologize for the tone I used.


Thank you. “Apologize” is definitely a magic word.

What was wrong was the fact that my words sounded like absolute 
blaming to someone/something.
But please, even if I was wrong with this tone (and I can confirm this 
again and again):  understand that


1) My intention was absolutely not to blame anything of Lilypond: as I 
told before, I consider the "bold"/plate approach of modern engraving 
as a problem for the readability of *all* the music engraving of any 
software/company.
Lilypond itself has nothing to do with this (nor Feta has to do with 
it: it’s simply a general rule, which I think derives from commercial 
reasons).


Well, in fact, LilyPond’s documentation claims the plate engraving 
approach to be the very specificity of LilyPond from the beginning. 
Looking at github.com/engraving-challenges/estrella 
, I find the other 
versions much lighter than LilyPond’s. Perhaps the software involved in 
the contest have evolved since, I don’t know.


2) My intention was absolutely not to press developers/maintainers to 
develop anything. My idea was, instead, to show how good it could be 
to use what I consider an *impressive* work *already done* by someone 
else. Just link it, do not develop anything.



I would like to emphasize that this is not at all simple. I agree that 
the technical part is reachable. Yet, this has consequences on the 
organization of the LilyPond ecosystem that have to be considered with care.


Fonts external to LilyPond also have development cycles that are 
different from LilyPond’s. If Gonville or other fonts were integrated as 
built-in options, we would end up receiving bug reports or feature 
requests from fellow users about fonts which we are incompetent about. 
It would force the authors of these fonts to follow LilyPond issues and 
make changes in parallel with Feta, for example, make it SMuFL-compliant 
by the end of the summer, which is very demanding. When the original 
author will not be available or no longer willing to support it, users 
will complain about the font not working and other LilyPond developers 
will need to fix it, and first learn its generation system, which is a 
custom one entirely different from Feta’s.


In the end, the LilyPond team is responsible (or feels responsible) for 
maintaining a piece of software that typesets music, and one music font. 
Adding built-in support for more fonts means officially supporting them, 
which entails more responsibility for developers, a responsibility that 
they need to be willing to accept and competent for undertaking. It’s 
another area in the multitude of areas of knowledge required to make 
LilyPond work across releases. See? To each their own problems.


Fonts are undergoing a very serious effort by Owen Lamb as part of GSoC, 
which should make LilyPond comply with the SMuFL standard and thus 
facilitate the use of many different fonts, not only Gonville. In fact, 
it recently came to my mind that if Feta is to become usable in other 
notation software, it could be an idea to move it to a separate 
repository, distribute OTF files alone, and include these in the 
distribution, which should also adress the built-in handling of other 
fonts along the way. First, it’s urgent to wait for Owen’s project to be 
completed. Then, when the right time comes, reflect about wether the 
LilyPond team and community are ready to accept this reorganization.


Sincerely,
Jean

Re: Accidentals' font

[Aaron Hill]

On 2020-07-07 5:07 pm, Paolo Prete wrote:

I have to apologize for the tone I used.

What was wrong was the fact that my words sounded like absolute blaming 
to

someone/something.


At the end of the day, all of us can benefit from learning to be more 
aware of how our words may be perceived.


I cannot find the original source, but I had heard it said the one time 
you can be certain someone is lying to you is when they begin by 
assuring you they are not lying.


So one bit of advice I can offer is the moment you preface a comment 
with a caveat, such as "I don't mean to sound , but...", stop 
right there and reflect.  More often than we probably care to admit, 
such a disclaimer is an outright fabrication.  I might say I do not mean 
it but in reality I very much mean it and am looking for any cheap 
excuse to get away with it.


It should be recognized there is value in writing out how you truly feel 
providing you have the mental wherewithal to not to actually post it.  
After venting pent-up frustrations, select that text and hit delete 
knowing your mind is now in a better place.  When you begin writing 
again, it should hopefully be easier to communicate your thoughts in an 
actionable and positive manner.



-- Aaron Hill

Re: Accidentals' font

[Paolo Prete]

I have to apologize for the tone I used.

What was wrong was the fact that my words sounded like absolute blaming to
someone/something.
But please, even if I was wrong with this tone (and I can confirm this
again and again):  understand that

1) My intention was absolutely not to blame anything of Lilypond: as I told
before, I consider the "bold"/plate approach of modern engraving as a
problem for the readability of *all* the music engraving of any
software/company.
Lilypond itself has nothing to do with this (nor Feta has to do with it:
it's simply a general rule, which I think derives from commercial reasons).

2) My intention was absolutely not to press developers/maintainers to
develop anything. My idea was, instead, to show how good it could be to use
what I consider an *impressive* work *already done* by someone else. Just
link it, do not develop anything.

That's all. This is not a way to say: "I was wrong/bad but you were wrong
too". It's just a clarification of my intention. The tone used produced the
opposite reaction.
Also: don't consider too much what I wrote. It's not important what I
wrote; what deserves attention is, instead, the work behind this font.
Please look at it!

In any case, I'll continue to contribute to the project, with my tools.
I'm pretty sure I can release a pretty tool for doing insane things with
piano scores.
Then, even if with no feedback, I'll publish many examples in the next few
days, hoping they could be useful (as Lilypond was and is useful for me)

Sincerily,
P



On Wed, Jul 8, 2020 at 1:03 AM Jean Abou Samra  wrote:

> Greetings everybody,
>
> I'm extremely upset to discover this thread.
>
> I was about to send a very, very long e-mail. Then I realized it was an
> excellent candidate for being perceived as lecturing all the
> participants. So instead, I encourage everyone to read
> https://snarky.ca/why-i-took-october-off-from-oss-volunteering/.
>
> Overall, discussing about LilyPond should remain a pleasure for all the
> people involved.
>
> Sincerely,
> Jean
>
>
>

Re: Accidentals' font

[Jean Abou Samra]

Greetings everybody,

I'm extremely upset to discover this thread.

I was about to send a very, very long e-mail. Then I realized it was an 
excellent candidate for being perceived as lecturing all the 
participants. So instead, I encourage everyone to read 
https://snarky.ca/why-i-took-october-off-from-oss-volunteering/.


Overall, discussing about LilyPond should remain a pleasure for all the 
people involved.


Sincerely,
Jean

Re: Accidentals' font

[Kieren MacMillan]

Hi Paolo,

> > I can provide other examples if you are interested.
> Then it is pretty strange that you were interested in commenting on something 
> that is not of your interest ;-)

I didn’t say the first example wasn’t of my interest.
You seem to have difficulty reading.  ;-)

Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: Accidentals' font

[Paolo Prete]

On Sun, Jul 5, 2020 at 12:14 AM Kieren MacMillan <
kieren_macmil...@sympatico.ca> wrote:

> Hi Paolo,
>
> > What would you consider more readable?
>
> The Feta version.
> The only objection I have is to the kerning in mf — otherwise, I think the
> Feta version is more readable.
>
>
Not so trivial to judge. In my knowledge a dynamic is really readable when
it's strongly coupled to the note it belongs to.
Otherwise, what is readable is the glyph. When you have m and f separated,
the glyph itself it's more readable, but not the pair note-dynamic.
And playability doesn't privilege aesthetics...



> > I can provide other examples if you are interested.
>
>
Then it is pretty strange that you were interested in commenting on
something that is not of your interest ;-)




>

Re: Accidentals' font

[Kieren MacMillan]

Hi Paolo,

> What would you consider more readable?

The Feta version.
The only objection I have is to the kerning in mf — otherwise, I think the Feta 
version is more readable.

> I can provide other examples if you are interested.

I’m not… but maybe others are.

Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: Accidentals' font

[Paolo Prete]

>
>
> About this question, I gave an answer to Han-Wen. For example, I consider
> objective data that a fraction where the mumerator is not joined to the
> denominator is more readable.
> Also, look at the attached image in response to Kevin (clefs) with the red
> lines. I consider it objective as well.
>
>
>

Also: look at the attached image.
What would you consider more readable? In this case, the more a dynamic is
restricted to its column, the more it is readable (in the sense: it's more
playable because you can better understand what is its corresponding note).

In order to do this, the chars "m" and "f" were put very close.
Also: in Feta they are separated, but they are not separated in the mp
dynamic...

I can provide other examples if you are interested.


testmfmp.pdf
Description: Adobe PDF document

Re: Accidentals' font

[Paolo Prete]

On Sat, Jul 4, 2020 at 10:45 PM Carl Sorensen 
wrote:

>
>
> On Sat, Jul 4, 2020 at 2:31 PM Paolo Prete  wrote:
>
>> 
>> I think there is an incomprehension in the meaning of my words.
>> Unfortunately this does not depend on Lilypond but on commercial logic in
>> the production of musical fonts today. Today it seems to me that music
>> software producers are more interested in the captivating aspect of fonts
>> than in their actual readability. This is normal, otherwise they could not
>> sell their products. Consequently, this is why there is a great
>> proliferation of bold fonts of the "plate engraving" type. If you look at
>> the trill glyph in Gonville, it appears much simpler than those that are
>> commonly used. Commercially I think it would have little success. But
>> Gonville's trill glyph does not aim to be captivating; it aims to be more
>> readable.
>> Lilypond currently has two possibilities:
>>
>> 1) use the Feta font (---> "plate engraving approach") as do the other
>> notation softwares.
>>
>> 2) use the Gonville font (---> "readability / playability approach")
>>
>>
> Do you have any objective data that says Gonville is more
> readable/playable than Feta?  Or is this your opinion?
>
> Carl
>
>

About this question, I gave an answer to Han-Wen. For example, I consider
objective data that a fraction where the mumerator is not joined to the
denominator is more readable.
Also, look at the attached image in response to Kevin (clefs) with the red
lines. I consider it objective as well.

Re: Accidentals' font

[Urs Liska]

Am Samstag, den 04.07.2020, 10:06 -0500 schrieb Karlin High:
> On 7/4/2020 5:55 AM, Paolo Prete wrote:
> > Just leave Feta as a native font and insert a dummy
> > wrapper for Gonville in the ./configure. This does not require any
> > development, nor uniformity in the coding standard and can be
> > easily added
> > to the source tree.
> 
> This discussion is reminding me of the Google Summer of Code project 
> proposal, "Support for Style Sheets."
> 
> "
> LilyPond’s engraving output can be tweaked to the least detail, and
> one 
> important addition in recent years was the ability to use
> alternative 
> notation fonts. It is possible to create reusable modules for “house 
> styles”, but this project aims at bringing this to a new level by 
> creating a convenient extension package with support for creating, 
> applying, and sharing modular style sheets.
> "
> 
> 
> That looks to me like there IS community support for having ways to 
> change the look-and-feel of LilyPond's output, depending how the 
> development goals are defined and presented.

I just want to point out that there's an openLilyLib package 
https://github.com/openlilylib/notation-fonts which allows you to use
any installed (i.e. compatible) notation font as easily as

\include "oll-core/package.ily"
\loadPackage notation-fonts
\useNotationFont lilyjazz

This loads a default stylesheet provided for lilyjazz, but you can also
specify custom styles with

\useNotationFont \with {
  stylesheet = #'my-custom-style.ily
} haydn

The repository with the old OFL versions of Abraham Lee's work (which
includes Gonville BTW) has been mentioned, and Frescobaldi provides a
easy-to-use dialog to install and choose notation fonts with built-in
preview function.

Urs

Re: Accidentals' font

[Kieren MacMillan]

Hi Carl (et al.),

> Do you have any objective data that says Gonville
> is more readable/playable than Feta?  Or is this your opinion?

Must be his opinion, because I’ve put scores using Gonville and Feta in front 
of the same players, and many of them have said that Feta is easier to read 
(especially under pit-lighting conditions).

=)

Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: Accidentals' font

[Carl Sorensen]

On Sat, Jul 4, 2020 at 2:31 PM Paolo Prete  wrote:

> 
> I think there is an incomprehension in the meaning of my words.
> Unfortunately this does not depend on Lilypond but on commercial logic in
> the production of musical fonts today. Today it seems to me that music
> software producers are more interested in the captivating aspect of fonts
> than in their actual readability. This is normal, otherwise they could not
> sell their products. Consequently, this is why there is a great
> proliferation of bold fonts of the "plate engraving" type. If you look at
> the trill glyph in Gonville, it appears much simpler than those that are
> commonly used. Commercially I think it would have little success. But
> Gonville's trill glyph does not aim to be captivating; it aims to be more
> readable.
> Lilypond currently has two possibilities:
>
> 1) use the Feta font (---> "plate engraving approach") as do the other
> notation softwares.
>
> 2) use the Gonville font (---> "readability / playability approach")
>
>
Do you have any objective data that says Gonville is more readable/playable
than Feta?  Or is this your opinion?

Carl

Re: Accidentals' font

[Kieren MacMillan]

Hi Carl (et al.),

> I agree with Kevin.  You do not speak (even in this email) as if it is your
> opinion; you speak as if it is an undisputed fact.

+1

> I am, however, getting somewhat weary of your posts that say, in essence,
> "LilyPond does X incorrectly.  And it is obvious to anybody that only an
> idiot would do it that way, so LilyPond needs to change."
> […] that is the feeling I get when I read many of your posts.

+1

> because the justification for wanting Gonville is not expressed as
> a preference, but instead as a defect in Feta (which should
> apparently be obvious to everybody), I just tune it out.

+1

Maybe Paolo should add a disclaimer to his signature, like David K does?  ;)

Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: Accidentals' font

[Paolo Prete]

On Sat, Jul 4, 2020 at 8:46 PM Carl Sorensen 
wrote:


>
>
>> All the fonts on the earth have many issues. If you look at the score of
>> Debussy, it has *many* and *many* issues, and it was one of the best
>> engraving techniques at his time.
>>
>
> Again, in your opinion it had *many* and *many* issues.
>
>


perhaps we give two different meanings and weights to the word "issue".
Note that I have said that Debussy's edition was excellent in those days.
And the engraving company (Durand) one of the most important in history.
Don't give the word "issue" a negative meaning. I think that in this type
of task, "issue" is the most neutral thing in the world. That said, you say
that I should write "in my opinion".
But look at the first six bars of the prelude:

https://github.com/paolo-prete/Spontini/blob/master/examples/debussy-frag-1.jpeg

Is the dangling 1/4 rest at bar 4 an "issue" in my (Paolo) opinion or is it
an "issue" tout-court?
And what about the end of the slur of bar 2 at the beginning of bar 3?
And what about the triple hairpin on two notes in bar 3?
And what about the beam that overlaps the stem at bar 6?



> I appreciate your interest in LilyPond.  And I appreciate your willingness
> to develop a self-contained html editor to allow easy creation of visual
> tweaks, which are then captured in the source.  I know that you use that,
> and I expect others will use it as well.  Thank you for your contribution.
>
> I am, however, getting somewhat weary of your posts that say, in essence,
> "LilyPond does X incorrectly.  And it is obvious to anybody that only an
> idiot would do it that way, so LilyPond needs to change."
>
> I realize that my paragraph above is hyperbole, not literal.  And yet,
> that is the feeling I get when I read many of your posts.  The tenor of
> your message makes it difficult for me to appreciate the value of your
> observations.  For example, in the particular case of this request, it
> might be reasonable to ship a "gonville-install" script with LilyPond that
> could be run to download and install Gonville (I'm not sure what all the
> technical challenges of this are).  And it might be reasonable to have the
> gonville-install script set the default font for LilyPond to be Gonville
> (again, I don't know what all the technical challenges of this approach
> are).  But because the justification for wanting Gonville is not expressed
> as a preference, but instead as a defect in Feta (which should apparently
> be obvious to everybody), I just tune it out.
>
> Again, I sincerely thank you for your contributions to LilyPond.
>
>
I think there is an incomprehension in the meaning of my words.
Unfortunately this does not depend on Lilypond but on commercial logic in
the production of musical fonts today. Today it seems to me that music
software producers are more interested in the captivating aspect of fonts
than in their actual readability. This is normal, otherwise they could not
sell their products. Consequently, this is why there is a great
proliferation of bold fonts of the "plate engraving" type. If you look at
the trill glyph in Gonville, it appears much simpler than those that are
commonly used. Commercially I think it would have little success. But
Gonville's trill glyph does not aim to be captivating; it aims to be more
readable.
Lilypond currently has two possibilities:

1) use the Feta font (---> "plate engraving approach") as do the other
notation softwares.

2) use the Gonville font (---> "readability / playability approach")

The two aspects are complementary and I have hardly seen such an accurate
and meticulously made font as Gonville, in the sense of readability /
playability. This would certainly give, in my opinion, a strong
professional touch to the software.

And I also want to thank you, of course, for your contribution to Lilypond.
This is beyond doubt. Thanks to Lilypond I am free from the slavery of the
WYSIWYG. I really can't think of using better alternative software than it.

Re: Accidentals' font

[Carl Sorensen]

On Sat, Jul 4, 2020 at 9:25 AM Paolo Prete  wrote:

> On Sat, Jul 4, 2020 at 4:43 PM Kevin Barry  wrote:
>
> > > Again, I hope I am not unpleasant and polemic
> >
> > In my opinion, you are being both. If your goal was genuinely to
> > encourage improvements in LilyPond, then I hope it's clear from the
> > response that you are going about it in a poor way. Acting like it's
> > obvious that LilyPond's default font is badly designed is insulting,
> >
>
> I don't think so. Saying that Feta font has many issues, is absolutely not
> insulting.
>

I agree with Kevin.  You do not speak (even in this email) as if it is your
opinion; you speak as if it is an undisputed fact.

Personally, I prefer Feta to Gonville.  But I cannot say that Feta is
superior to Gonville, it is just my preference.


> All the fonts on the earth have many issues. If you look at the score of
> Debussy, it has *many* and *many* issues, and it was one of the best
> engraving techniques at his time.
>

Again, in your opinion it had *many* and *many* issues.


> For example, many excellent engravers do use the "Ped." classical symbol,
> IMHO so wide and messy. But they are excellent in any case.
> Music engraving is *in itself* an ocean of issues. Doing a good engraving
> is something like a Carthusian task and only in recent years things are
> generally improved, thanks to the technology.
> And we are very far from a shared "standard".
>

Since we are far from a shared standard, it is not helpful to speak in
absolute language about the performance of LilyPond.  Just because it
doesn't match your preference doesn't mean it's wrong.  Yet your emails
consistently speak of things being wrong, not just being different from
your preference.

I find it interesting that you accused me earlier of being harsh and
polemic, but you appear unable to recognize when your messages are harsh
and polemic.

I appreciate your interest in LilyPond.  And I appreciate your willingness
to develop a self-contained html editor to allow easy creation of visual
tweaks, which are then captured in the source.  I know that you use that,
and I expect others will use it as well.  Thank you for your contribution.

I am, however, getting somewhat weary of your posts that say, in essence,
"LilyPond does X incorrectly.  And it is obvious to anybody that only an
idiot would do it that way, so LilyPond needs to change."

I realize that my paragraph above is hyperbole, not literal.  And yet, that
is the feeling I get when I read many of your posts.  The tenor of your
message makes it difficult for me to appreciate the value of your
observations.  For example, in the particular case of this request, it
might be reasonable to ship a "gonville-install" script with LilyPond that
could be run to download and install Gonville (I'm not sure what all the
technical challenges of this are).  And it might be reasonable to have the
gonville-install script set the default font for LilyPond to be Gonville
(again, I don't know what all the technical challenges of this approach
are).  But because the justification for wanting Gonville is not expressed
as a preference, but instead as a defect in Feta (which should apparently
be obvious to everybody), I just tune it out.

Again, I sincerely thank you for your contributions to LilyPond.

Sincerely,

Carl Sorensen

Re: Accidentals' font

[Paolo Prete]

On Sat, Jul 4, 2020 at 4:43 PM Kevin Barry  wrote:

> > Again, I hope I am not unpleasant and polemic
>
> In my opinion, you are being both. If your goal was genuinely to
> encourage improvements in LilyPond, then I hope it's clear from the
> response that you are going about it in a poor way. Acting like it's
> obvious that LilyPond's default font is badly designed is insulting,
>

I don't think so. Saying that Feta font has many issues, is absolutely not
insulting.
All the fonts on the earth have many issues. If you look at the score of
Debussy, it has *many* and *many* issues, and it was one of the best
engraving techniques at his time.
For example, many excellent engravers do use the "Ped." classical symbol,
IMHO so wide and messy. But they are excellent in any case.
Music engraving is *in itself* an ocean of issues. Doing a good engraving
is something like a Carthusian task and only in recent years things are
generally improved, thanks to the technology.
And we are very far from a shared "standard".

And for the clef test I actually don't
> perceive any real difference other than the "C" for the time signature
> (and again, I prefer the thicker version).
>
>
I attach a clearer image of what I consider the issue (this in response to
Han Wen too, because my previous example was not clear). Red lines show how
the two areas overlap.


feta-gonville.pdf
Description: Adobe PDF document

Re: Accidentals' font

[Karlin High]

On 7/4/2020 5:55 AM, Paolo Prete wrote:

Just leave Feta as a native font and insert a dummy
wrapper for Gonville in the ./configure. This does not require any
development, nor uniformity in the coding standard and can be easily added
to the source tree.


This discussion is reminding me of the Google Summer of Code project 
proposal, "Support for Style Sheets."


"
LilyPond’s engraving output can be tweaked to the least detail, and one 
important addition in recent years was the ability to use alternative 
notation fonts. It is possible to create reusable modules for “house 
styles”, but this project aims at bringing this to a new level by 
creating a convenient extension package with support for creating, 
applying, and sharing modular style sheets.

"


That looks to me like there IS community support for having ways to 
change the look-and-feel of LilyPond's output, depending how the 
development goals are defined and presented.

--
Karlin High
Missouri, USA

Re: Accidentals' font

[Kevin Barry]

> Again, I hope I am not unpleasant and polemic

In my opinion, you are being both. If your goal was genuinely to
encourage improvements in LilyPond, then I hope it's clear from the
response that you are going about it in a poor way. Acting like it's
obvious that LilyPond's default font is badly designed is insulting,
and hiding insults behind your "opinion" isn't fooling anyone - it
just comes across as superior / talking down. If fonts were so easily
comparable as you are pretending, then we wouldn't have so many of
them.

The philosophy behind the design of LilyPond's default font was to
imitate plate engraving (which results in thicker lines than computer
engraving, partly because of "squeeze"), not to imitate another
computer font like Gonville, so all this Gonville talk is hot air. If
you don't like them that's not the fault of the font.

Regarding the attachments: in my opinion the lines in the sharp symbol
in Gonville are too thin and too close together - I have to squint at
it to see the gap properly. And for the clef test I actually don't
perceive any real difference other than the "C" for the time signature
(and again, I prefer the thicker version).

Kevin

Re: Accidentals' font

[Jan Nieuwenhuizen]

Han-Wen Nienhuys writes:

Hi!

>> 7) Look at the trill glyph: it's simpler, cleaner and less "baroque",
>
> Maybe Jan can comment. The comment says it's based on a Saint Saens
> Cello concerto, which I can't recall ever having seen.

Yes, I have some recollection of that.  You are probably aware that some
of the inspiration of the Feta font came from the fact that in those
days the vast majority of computer music engravings were way too light.

I can imagine that we may have overshot a little bit, just like I can
imagine that a subsequent reaction to LilyPond's blackness/heaviness
(especially in this era where people have become more accustomed to
light engravings) will probaly also overshoot a bit; certainly to my
taste.

Greetings,
Janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: Accidentals' font

[Lukas-Fabian Moser]

Hi Han-Wen,


6) Look at the glyph of forcing: it forms a single word, and not the union
of three different characters (which is very distracting, in my opinion)

what is 'forcing' ?
I assumed it meant sfz, coming from an Italian native speaker - Paolo, 
please correct me if I'm wrong.

7) Look at the trill glyph: it's simpler, cleaner and less "baroque",

Maybe Jan can comment. The comment says it's based on a Saint Saens
Cello concerto, which I can't recall ever having seen.


Seems plausible: Everybody (tm) plays the 1st concerto, and at least 
15-20 years ago, everybody (tm) used the Durand edition. There you find:


Not really identical to LilyPond's current

but certainly related.

Lukas

Re: Accidentals' font

[Han-Wen Nienhuys]

On Fri, Jul 3, 2020 at 11:42 PM Paolo Prete  wrote:
> *All* my opinions are personal opinions. And I don't expect they will be
> followed or implemented.

If you really expect that, why bother sending this email?

Let's all just assume that they're not just your personal opinions,
but that you have found genuine defects in the font. We're not going
to adjust glyphs because they don't conform to your opinion. We can
adjust glyphs if we find there are bugs in them.

> Meanwhile, for anyone interested I focus on some aspects that IMHO make
> that font really desirable for Lilypond, at least as an option. Be free to
> agree or not agree: here is my list
>
> 1) Look at the treble clef. IMHO Lilypond doesn't need to be so high, and
> in fact the author of the font has reduced its height. Using a treble clef
> higher than necessary leads to spacing problems between staves.

I actually doubt this. The clef is at the start of the line, and there
are usually no things sticking out of the bottom of the at the start
of the previous line.

> 2) In general, for keys, there is no need to use bold glyph. The default
> bold glyphs, which are Bravura's philosophy (AFAIK), were fine when

Can you explain what you mean with "bold" glyphs. The accidentals only
exist in one flavor.

> 3) Look at the time signature. In the Feta font the two numbers overlap and
> can be annoying at the sight, IMHO. This problem was solved by the Gonville
> font.

Can you file a bug with an image? Over here, the digits do not overlap
with each other, but do overlap slightly with the staff lines. (see
attachment).

> 4) Look at the sharp glyph: it is reduced in width, saving space and
> remaining perfectly legible at the same time.

The gonville font is well done, but we usually base formatting
decisions on plate engravings. Could you do some measurements to
demonstrate what ranges of dimensions (relative to staff space) are
common?

> 5) Look at the flat glyph: the horizontal line has been reduced in
> thickness, which once again pairs well with lighter staves and stems.

The flat glyph has no horizontal line. You can see the glyph it was
based on over here:

http://lilypond.org/doc/v2.19/Documentation/essay/engraving-details.en.html

note that the feta glyph is actually lighter than its inspiration.

> 6) Look at the glyph of forcing: it forms a single word, and not the union
> of three different characters (which is very distracting, in my opinion)

what is 'forcing' ?

> 7) Look at the trill glyph: it's simpler, cleaner and less "baroque",

Maybe Jan can comment. The comment says it's based on a Saint Saens
Cello concerto, which I can't recall ever having seen.

> 8) Look at the bequadro glyph: the Feta one is too large compared to the
> NoteHead and this has also been corrected in the gonville font.

Scans? "Too large": do you mean too wide, or too high?

> I could go on with many other details.

Thanks. I could go on asking questions, but I am really looking for
data rather than opinions.

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: Accidentals' font

[Paolo Prete]

>
> > This addition does not involve any development. All the stuff is already
> > developed. Just simply, AFAIK, add the fonts to their respective
> > directories, as I have already done.
>
> Here are some things to consider:
>
> * You point to modern printers generating thinner lines. However, the
> design objective of Feta was to mimic plate engraving with thicker
> lines. In that sense it is working as intended, even if it is not your
> preferred style.
>
>
I don't think so.

I'm sorry if I can seem overly punctilious, pedantic and unpleasant (and I
repeat that these are my * personal * observations), but look at this score:

https://ks.imslp.net/files/imglnks/usimg/0/0c/IMSLP521885-PMLP2394-Debussy_Claude-Pr%C3%A9ludes_1er_Livre_Durand_7687_scan.pdf

The lines are thick and it's plate engraving dated 1902!
The numerator and the denominator of the time signature are bold enough for
these thicknesses but never overlap, unlike Feta.
See also the trill glyph on page 44. You can notice that Feta has too thin
curves combined with too thick curves, while in Debussy's score all the
trill curves are modeled on a more or less uniform thickness, consistent
with the thickness of the lines.



> (I do accept the blame for the font being a haphazard collection of
> individual glyphs I happened to like, rather than a coherent
> ensemble.)
>
> * LilyPond is built from source. Although rare, it does happen that we
> tweak glyphs (for example, see the work that Owen Taylor is doing for
> Smufl support).  This process doesn't work well with Gonville, as it
> is not generated with Metafont. How do you envision development
> happening with Gonville as a standard font?
>
>

This is not a problem. Just leave Feta as a native font and insert a dummy
wrapper for Gonville in the ./configure. This does not require any
development, nor uniformity in the coding standard and can be easily added
to the source tree. Using a flag like --with-gonville-font you can also be
sure that if the Gonville src is not aligned with the source of Lilypond,
the compilation will give an error. At this point the user will be able to
remove the flag and continue compiling. There are many similar examples.
For example x264 is not a native codec for ffMPEG, but it is the * de facto
* codec for it and is added to the project via a simple wrapper.

(politically correct Disclaimer ;-) ):
Before anyone gets annoyed by all these considerations, I repeat that I am
all personal opinions, without wanting to convince anyone but it is my goal
only to invite to meditate on the subject. And in particular they are
determined by the fact that, from what I have observed, the work on
Gonville is truly impressive and meticulous. I think anyone can observe
these details.




>

Re: Accidentals' font

[Han-Wen Nienhuys]

On Fri, Jul 3, 2020 at 11:42 PM Paolo Prete  wrote:
> I could go on with many other details.
> Which is of course my simple opinion; in any case I'm not asking to
> implement anything. I'm just asking to add the excellent work done by the
> author of the Font. A very meticulous work for which I thank him very much.
>
> This addition does not involve any development. All the stuff is already
> developed. Just simply, AFAIK, add the fonts to their respective
> directories, as I have already done.

Here are some things to consider:

* You point to modern printers generating thinner lines. However, the
design objective of Feta was to mimic plate engraving with thicker
lines. In that sense it is working as intended, even if it is not your
preferred style.

(I do accept the blame for the font being a haphazard collection of
individual glyphs I happened to like, rather than a coherent
ensemble.)

* LilyPond is built from source. Although rare, it does happen that we
tweak glyphs (for example, see the work that Owen Taylor is doing for
Smufl support).  This process doesn't work well with Gonville, as it
is not generated with Metafont. How do you envision development
happening with Gonville as a standard font?

> Hope this can help.

I think the most practical solution is to wait for Smufl support for
LilyPond, which should make it easier to use a wide array of music
fonts.

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: Accidentals' font

[Paolo Prete]

On Fri, Jul 3, 2020 at 10:19 PM Werner LEMBERG  wrote:

>
>

> > I don't understand why this is not part of Lilypond's project.  I
> > would use it as default.  But, at least, it should be added as a
> > ready-to-use option.
>
> You might not be aware because English is not your mother tongue, but
> what you write is very demanding and doesn't provide good feeling.
> Actually, a lot of developers are quite allergic to this kind of
> attitude.
>
> If you would write
>
>   ... I can imagine that it would be great to have it as a
>   ready-to-use option ...
>
> or something like that, this would be much more inviting.  In summary:
> Don't advertise your opinion as the only truth.



*All* my opinions are personal opinions. And I don't expect they will be
followed or implemented.

Meanwhile, for anyone interested I focus on some aspects that IMHO make
that font really desirable for Lilypond, at least as an option. Be free to
agree or not agree: here is my list

1) Look at the treble clef. IMHO Lilypond doesn't need to be so high, and
in fact the author of the font has reduced its height. Using a treble clef
higher than necessary leads to spacing problems between staves.

2) In general, for keys, there is no need to use bold glyph. The default
bold glyphs, which are Bravura's philosophy (AFAIK), were fine when
precision printers did not exist, because they were proportionate to the
thickness of the lines and stems.

3) Look at the time signature. In the Feta font the two numbers overlap and
can be annoying at the sight, IMHO. This problem was solved by the Gonville
font.

4) Look at the sharp glyph: it is reduced in width, saving space and
remaining perfectly legible at the same time.

5) Look at the flat glyph: the horizontal line has been reduced in
thickness, which once again pairs well with lighter staves and stems.

6) Look at the glyph of forcing: it forms a single word, and not the union
of three different characters (which is very distracting, in my opinion)

7) Look at the trill glyph: it's simpler, cleaner and less "baroque",

8) Look at the bequadro glyph: the Feta one is too large compared to the
NoteHead and this has also been corrected in the gonville font.

I could go on with many other details.
Which is of course my simple opinion; in any case I'm not asking to
implement anything. I'm just asking to add the excellent work done by the
author of the Font. A very meticulous work for which I thank him very much.

This addition does not involve any development. All the stuff is already
developed. Just simply, AFAIK, add the fonts to their respective
directories, as I have already done.

Hope this can help.

Best,

P


>

Re: Accidentals' font

[Werner LEMBERG]

Paolo,


I feel obliged to write this e-mail so that we have a healthy and
friendly environment to discuss everything related to LilyPond, free
of friction as much as possible.  I remember previous e-mail exchanges
with you and the list where similar issues surfaced.

> I don't understand why this is not part of Lilypond's project.  I
> would use it as default.  But, at least, it should be added as a
> ready-to-use option.

You might not be aware because English is not your mother tongue, but
what you write is very demanding and doesn't provide good feeling.
Actually, a lot of developers are quite allergic to this kind of
attitude.

If you would write

  ... I can imagine that it would be great to have it as a
  ready-to-use option ...

or something like that, this would be much more inviting.  In summary:
Don't advertise your opinion as the only truth.  I guess you don't
mean it, but please always tag personal opinions as such.  Every time.

Otherwise you will get replies – if at all – like 'use the source,
Luke', or 'patches are welcome', and nothing else.  We all are
volunteers.


Werner

Re: Accidentals' font

[Paolo Prete]

On Fri, Jul 3, 2020 at 6:05 PM Xavier Scheuer  wrote:

> On Fri, 3 Jul 2020 at 16:54, Paolo Prete  wrote:
> >
> > They are good, but not GPL/open source...
>
> Hello Paolo,
>
> Most of them were open source initially (Open Font License).
> There are repositories with the OFL-licensed versions here:
> https://github.com/OpenLilyPondFonts
>
> Recently Daniel Benjamin Miller shared (on lilypond-user mailing list) his
> work for a better support for Bravura (also OFL) in LilyPond:
> https://github.com/dbenjaminmiller/bmusicfonts
>
> In the past talented developers (sorry, I do not remember who exactly but
> thanks!) implemented a simple way to replace the music font, see NR 3.4.4
> Replacing the notation font
>
> http://lilypond.org/doc/v2.21/Documentation/notation/replacing-the-notation-font.html
>
> And presently Owen Lamb is implementing (GSoC 2020) SMuFL support in
> Lilypond.
>
> I mean, it can always be improved but I am grateful for the work people
> have done so far.
>
> Cheers,
> Xavier
>
> --
>

Hello Xavier,

Thank you for the links.
However, from what I see, they are more or less a "stylistic" choice.
Instead, the Gonville font has a *functional* point of view that solves
many issues of the Feta Font.
If you look at its glyphs you can see that there's a meticulous work of
making them optimized for *reading*.
I don't understand why this is not part of Lilypond's project.
I would use it as default. But, at least, it should be added as a
ready-to-use option.

Best,
P



>

Re: Accidentals' font

[Xavier Scheuer]

On Fri, 3 Jul 2020 at 16:54, Paolo Prete  wrote:
>
> They are good, but not GPL/open source...

Hello Paolo,

Most of them were open source initially (Open Font License).
There are repositories with the OFL-licensed versions here:
https://github.com/OpenLilyPondFonts

Recently Daniel Benjamin Miller shared (on lilypond-user mailing list) his
work for a better support for Bravura (also OFL) in LilyPond:
https://github.com/dbenjaminmiller/bmusicfonts

In the past talented developers (sorry, I do not remember who exactly but
thanks!) implemented a simple way to replace the music font, see NR 3.4.4
Replacing the notation font
http://lilypond.org/doc/v2.21/Documentation/notation/replacing-the-notation-font.html

And presently Owen Lamb is implementing (GSoC 2020) SMuFL support in
Lilypond.

I mean, it can always be improved but I am grateful for the work people
have done so far.

Cheers,
Xavier

-- 
Xavier Scheuer 

Re: Accidentals' font

[Paolo Prete]

This is *MUCH* better for *MANY* and *MANY* reasons, thanks.
The more I observe them, the more I find excellent adjustments.
They also save useful space.
The only glyph that I don't like is the fermata one. The dot is too small
and, therefore:

1) it does not differ well from the staccato glyph.
2) it does not bring enough attention of the reader to the glyph

Why are they not already included in Lilypond? It would be really bad to
have troubles with compatibility issues with such a beautiful work...

Best,
P


On Fri, Jul 3, 2020 at 5:17 PM James Lowe  wrote:

> On 03/07/2020 13:48, Paolo Prete wrote:
> > Hello,
> >
> > 1) Is there a GPL or open-source alternative for FETA fonts for
> accidentals
> > that can be used with Lilypond? (If so, is there an example of how to use
> > them)?
>
> https://www.chiark.greenend.org.uk/~sgtatham/gonville/
>
>
> ?
>
> James
>
>
>
>

Re: Accidentals' font

[James Lowe]

On 03/07/2020 13:48, Paolo Prete wrote:

Hello,

1) Is there a GPL or open-source alternative for FETA fonts for accidentals
that can be used with Lilypond? (If so, is there an example of how to use
them)?


https://www.chiark.greenend.org.uk/~sgtatham/gonville/


?

James

Re: Accidentals' font

[Paolo Prete]

They are good, but not GPL/open source...

On Fri, Jul 3, 2020 at 4:00 PM Andrew Bernard 
wrote:

> Nothing at Abraham Lee's satisfies you?
>
> https://www.musictypefoundry.com
>
> Andrew
>
>
> On 3/07/2020 10:48 pm, Paolo Prete wrote:
> > Hello,
> >
> > 1) Is there a GPL or open-source alternative for FETA fonts for
> accidentals
> > that can be used with Lilypond? (If so, is there an example of how to use
> > them)?
> >
> >
>
>

Re: Accidentals' font

[Andrew Bernard]

Nothing at Abraham Lee's satisfies you?

https://www.musictypefoundry.com

Andrew


On 3/07/2020 10:48 pm, Paolo Prete wrote:

Hello,

1) Is there a GPL or open-source alternative for FETA fonts for accidentals
that can be used with Lilypond? (If so, is there an example of how to use
them)?

Accidentals' font

[Paolo Prete]

Hello,

1) Is there a GPL or open-source alternative for FETA fonts for accidentals
that can be used with Lilypond? (If so, is there an example of how to use
them)?

2) IMHO these default accidentals should be changed or improved. The
biggest problem is their vertical lines, which are too bold. As soon as you
reduce the thickness of stems and staff lines - which is *very*, *very*
common in modern engraving, because today we have good printers - these
accidentals are bad to see.

Please give me feedback about this: this is not intended to be polemic, I
think that if it's not possible to do it natively, then it is an issue
which can be easily fixed and I think it deserves further study.

Best,
P