lilypond-devel
[Top][All Lists]
Advanced

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

Re: Accidentals' font


From: Paolo Prete
Subject: Re: Accidentals' font
Date: Wed, 8 Jul 2020 15:31:30 +0200

On Wed, Jul 8, 2020 at 12:13 PM Jean Abou Samra <jean@abou-samra.fr> wrote:


> t to press developers/maintainers to develop anything. My idea was,
> instead, to show how good it could be to use what I consider an
> *impressive* work *already done* by someone else. Just link it, do not
> develop anything.
>
>
> 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).
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.

Best,

P


reply via email to

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