On Thu, Jul 9, 2020 at 8:35 PM Jean Abou Samra <j...@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 <j...@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
