Re: SMuFL

[Urs Liska]

Am 11.08.2013 14:43, schrieb David Kastrup:
> Urs Liska <address@hidden> writes:
>
> > Am 10.08.2013 10:30, schrieb David Kastrup:
> > > Andrew Bernard <address@hidden> writes:
> > >
> > > > This is of great interest to me because several of the people I do
> > > > scores for (contemporary composers) do not favour the very heavy black
> > > > Germanic look of the standard lilypond font, attractive though it may
> > > > be. It would be nice to have a wider choice to offer in the future,
> > > > and if SMuFL takes off as a standard, there may well be many fonts to
> > > > choose from.
> > > Do you really think that proprietary music system vendors will release
> > > their fonts in a usable form under free licenses so that people can
> > > forego buying their software and use LilyPond instead?
> > "Steinberg is making Bravura available under the SIL Open Font
> > License."  That's a start.
> Yes.
>
> > Adobe won't release their fonts under an open license, nevertheless
> > we're happy to have standards that allow us to freely select from free
> > and non-free fonts.
> Correction: that allow those people for which unfree licensing is not an
> issue to select from free and non-free fonts.
OK, got it.
> That is outside of the
> scope of the GNU project, however.
What does this exactly mean?
I don't think a GNU project should actively _prevent_ the use of 
non-free software/fonts. Otherwise one should remove Pango as this 
allows one to use non-free text fonts.
IIUC this means a GNU project shouldn't endorse the use of non-free 
software, or take any voluntary actions to support this. Right?

But if for example someone would (hypothetically) provide a means to use 
alternative fonts, this contribution wouldn't have to be rejected, 
right? Otherwise one should remove Pango as soon as possible too ...
> At any rate, LilyPond does not have the infrastructure to select its
> music from different music fonts right now, even if we are not talking
> about the coding vector and metric problems regarding supporting a
> prescribed standard.
So I second Andrew's question: can you point to some revealing 
discussion (I don't hope for reference material) as to where the problem 
is with supporting _any_ other font?
Is it that Feta is so intertwined with LilyPond's layout process that 
it's hard to do anything different? Similar to how one should imagine 
the relation between LilyPond's Scheme and C++ layers?

Urs
>