Re: Accidentals' font

[Urs Liska]

Am Donnerstag, den 09.07.2020, 21:40 +0200 schrieb 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.
> 

But I'd like to repeat that the fonts created by Abraham (including
Gonville) are at least partially available as free fonts, and they
already *can* be used in a regular LilyPond installation without any
hassles.

All you need to do is copy (or better link) the font files in the fonts
directory (Frescobaldi even offers a nice interface for handling that
for arbitrary new LilyPond installations) and add some code to the
paper block of your document. 
If you use openLilyLib this is as easy as \useNotationFont Gonville.
The notation-fonts package even provides (optional) default stylesheets
for all supported fonts (to provide a good starting point regarding
e.g. line thicknesses).

So I really don't see the need for a patched compilation of LilyPond.
Urs

>  Best,
> P