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
<https://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
