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 <jean@abou-samra.fr 
> <mailto:jean@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