[Top][All Lists]

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

Re: Accidentals' font

From: Paolo Prete
Subject: Re: Accidentals' font
Date: Thu, 9 Jul 2020 21:40:48 +0200

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

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.


reply via email to

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