Re: Accidentals' font

[Paolo Prete]

On Thu, Jul 9, 2020 at 8:35 PM Jean Abou Samra <jean@abou-samra.fr> wrote:

> 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>
> 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 lilypond.org.
>

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.

 Best,
P