Urs Liska <u...@openlilylib.org> writes: > Am 11.08.2013 14:43, schrieb David Kastrup: >> Urs Liska <u...@openlilylib.org> 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 _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
