Re: SMuFL

[David Kastrup]

Urs Liska <address@hidden> writes:

> Am 11.08.2013 14:43, schrieb David Kastrup:
>> Urs Liska <address@hidden> writes:
>>
>>> 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?

That there is no point in complicating the project with code that will
not benefit free software users.

> I don't think a GNU project should actively _prevent_ the use of
> non-free software/fonts.

AS long as the Bravura font is available under the SIL open font
license, this is not really relevant to this discussion.  But at any
rate, the issue is putting logic in with the _sole_ purpose of
supporting non-free software.  That's not useful for a GNU project.

> Otherwise one should remove Pango as this allows one to use non-free
> text fonts.

It also allows one to use 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?

"take voluntary actions" is somewhat misleading as a project does not
take actions.  People do.  Everybody is free to write code for
supporting non-free software.  But that does not mean that it makes
sense for such support to be included upstream, and a GNU project should
avoid inciting people to invest their work in venues not benefitting
free software.

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

Pango supports free fonts.

>> 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?

What's wrong with searching the mailing lists and issue tracker for
"Gonville"?

> 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?

We are going in circles.  LilyPond does not support using more than a
single music font.  You can _overwrite_ LilyPond's font with Gonville
(which has the identical layout), yielding a version of LilyPond _only_
using Gonville as music font.  But you can't choose.  Your installation
supports one or the other.

Supporting more than one font layout plays second fiddle to supporting
more than one font.

Once supporting more than one font is possible, it would likely be
feasible to create a _conversion_ from SMuFL to LilyPond's layout and
metrics.  Of course, that would not really be contributing anything back
to SMuFL or Steinberg but it would likely be easier than making LilyPond
work with more than one font type.

-- 
David Kastrup