[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Accidentals' font

From: Jean Abou Samra
Subject: Re: Accidentals' font
Date: Thu, 9 Jul 2020 20:35:40 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

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


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 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,



reply via email to

[Prev in Thread] Current Thread [Next in Thread]