Le 08/07/2020 à 15:31, Paolo Prete a écrit :
On Wed, Jul 8, 2020 at 12:13 PM Jean Abou Samra <j...@abou-samra.fr
<mailto:j...@abou-samra.fr>> 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
