Re: Follow-up question to alternate music fonts
Urs Liska wrote Actually that's what I mean. I suggest to add the _ability_ to easily change the notation font through the make-pango-tree approach and let the user install additional fonts at will. As said this is the same as with any other (notation or any other) program. Of course you expect your word processor to let you choose from arbitrary fonts, but you're completely OK with installing fonts yourself. Urs Urs has the right idea. I never meant that the fonts needed to be included in the LilyPond code base, only more like an add-in function, so that probably answers my own question. For now, I'll look into the appropriate way/place to make these alternate fonts available to those who'd like to use them. Thank you all for your comments and thoughts on this matter! Happy Engraving! Abraham P.S. Urs, Unfortunately, the build scripts I use to create these fonts don't automatically pull the Bravura glyphs and put them in the right places for use in LilyPond. There were too many little things I did to put together the Profondo font that it's not an automated process. In any case, I don't think Bravura will be changing much, so I don't know if this will be much of a need in the future. I suppose an automated script for converting a SMuFL-compatible font to a LilyPond-compatible font could be created, but there'd have to be more of them out there for that to be useful since there's currently only Bravura follows this standard. I guess we'll see. Oh, and I looked into creating new functions so that the default ones can still be used. This is not difficult, but still requires a patched font.scm since the new functions also need to live in that file to work properly. They require some of the variables that exist only within the scope of the other classes/functions/variables in that file. I guess that's all for now :) -- View this message in context: http://lilypond.1069038.n5.nabble.com/Follow-up-question-to-alternate-music-fonts-tp164259p164385.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Follow-up question to alternate music fonts
Hi, 2014-07-10 19:25 GMT+02:00 tisimst tisi...@gmail.com: All, Is there anyone who is VERY against distributing music fonts in binary form (i.e., as otf, svg, etc.files)? I just don't see how we can make other music fonts available by forcing them to have a metafont source file. I guess that could be nice, but it seems like so much work to do that. I have about 4 or 5 alternate music fonts that people could use and I certainly don't want to convert them to metafont. They are currently designed and built with fontforge. What do you think? Does fontforge have its own format that contains a source-like description of the fonts? (i have no idea how it works, all my font work was with Metafont) Maybe we could distribute that? I'd say that it's important to distribute the fonts in a format that is most accessible for modification, but if all we have is binary files, then we have to live with that. cheers, Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Follow-up question to alternate music fonts
tisimst tisi...@gmail.com writes: All, Is there anyone who is VERY against distributing music fonts in binary form (i.e., as otf, svg, etc.files)? I just don't see how we can make other music fonts available by forcing them to have a metafont source file. I guess that could be nice, but it seems like so much work to do that. I have about 4 or 5 alternate music fonts that people could use and I certainly don't want to convert them to metafont. They are currently designed and built with fontforge. What do you think? Spirit of the GPL is delivering source code, defined as preferred form of modification, including all scripts etc. Now fonts are reasonably separate anyway, but that's what we should stick with. METAFONT is just one possibility here. If the fonts are derived from some upstream source, automating the derivation as much as possible makes sense in order to facilitate integrating future improvements from upstream. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Follow-up question to alternate music fonts
Am 11.07.2014 07:00, schrieb David Kastrup: tisimst tisi...@gmail.com writes: All, Is there anyone who is VERY against distributing music fonts in binary form (i.e., as otf, svg, etc.files)? I just don't see how we can make other music fonts available by forcing them to have a metafont source file. I guess that could be nice, but it seems like so much work to do that. I have about 4 or 5 alternate music fonts that people could use and I certainly don't want to convert them to metafont. They are currently designed and built with fontforge. What do you think? Spirit of the GPL is delivering source code, defined as preferred form of modification, including all scripts etc. Now fonts are reasonably separate anyway, but that's what we should stick with. METAFONT is just one possibility here. If the fonts are derived from some upstream source, automating the derivation as much as possible makes sense in order to facilitate integrating future improvements from upstream. IIRC Abraham uses scripts to bring existing fonts (e.g. Bravura) to the usable form. If that should be a completely automated process and would for example make it possible to update the Profondo font automatically if a new version of Bravura comes out that would be quite good. Bravura itself is *not* delivered as source code, for example. Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Follow-up question to alternate music fonts
On 11/07/14 08:01, Urs Liska wrote: Am 11.07.2014 07:00, schrieb David Kastrup: tisimst tisi...@gmail.com writes: All, Is there anyone who is VERY against distributing music fonts in binary form (i.e., as otf, svg, etc.files)? I just don't see how we can make other music fonts available by forcing them to have a metafont source file. I guess that could be nice, but it seems like so much work to do that. I have about 4 or 5 alternate music fonts that people could use and I certainly don't want to convert them to metafont. They are currently designed and built with fontforge. What do you think? Spirit of the GPL is delivering source code, defined as preferred form of modification, including all scripts etc. Now fonts are reasonably separate anyway, but that's what we should stick with. METAFONT is just one possibility here. If the fonts are derived from some upstream source, automating the derivation as much as possible makes sense in order to facilitate integrating future improvements from upstream. IIRC Abraham uses scripts to bring existing fonts (e.g. Bravura) to the usable form. If that should be a completely automated process and would for example make it possible to update the Profondo font automatically if a new version of Bravura comes out that would be quite good. Bravura itself is *not* delivered as source code, for example. Urs I guess I am missing something here. Why do we need other fonts as part of LilyPond anyway? In that I can already use (can I not?) any font that I have installed with the appropriate markup command, I can see why emmentaler and feta were included as that was what Han and Jan 'created' when they created LilyPond and I can also understand why we have users that extend the glyphs (all the weird and wonderful arrows and dots and shapes for noteheads etc.), after all LilyPond needs at least one font to base its code on. So what is the point of including more *as part of the code base*? This isn't meant as any kind of argument against or questioning of the request to add another font, I just don't understand what the purpose would be, other than 'because we can'. My only concern is that we then need to include these new fonts (if applicable) as part of the regression test suite surely? And make sure that LilyPond's spacing calculations are not going to be compromised by the addition of new fonts and that it isn't going to start to create more exceptions because one font's dynamic 'f' happens to be wider or fatter than LilyPond's (if you see what I am getting at). Regards James ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Follow-up question to alternate music fonts
Am 11.07.2014 10:16, schrieb James: On 11/07/14 08:01, Urs Liska wrote: Am 11.07.2014 07:00, schrieb David Kastrup: tisimst tisi...@gmail.com writes: All, Is there anyone who is VERY against distributing music fonts in binary form (i.e., as otf, svg, etc.files)? I just don't see how we can make other music fonts available by forcing them to have a metafont source file. I guess that could be nice, but it seems like so much work to do that. I have about 4 or 5 alternate music fonts that people could use and I certainly don't want to convert them to metafont. They are currently designed and built with fontforge. What do you think? Spirit of the GPL is delivering source code, defined as preferred form of modification, including all scripts etc. Now fonts are reasonably separate anyway, but that's what we should stick with. METAFONT is just one possibility here. If the fonts are derived from some upstream source, automating the derivation as much as possible makes sense in order to facilitate integrating future improvements from upstream. IIRC Abraham uses scripts to bring existing fonts (e.g. Bravura) to the usable form. If that should be a completely automated process and would for example make it possible to update the Profondo font automatically if a new version of Bravura comes out that would be quite good. Bravura itself is *not* delivered as source code, for example. Urs I guess I am missing something here. Why do we need other fonts as part of LilyPond anyway? In that I can already use (can I not?) any font that I have installed with the appropriate markup command, I can see why emmentaler and feta were included as that was what Han and Jan 'created' when they created LilyPond and I can also understand why we have users that extend the glyphs (all the weird and wonderful arrows and dots and shapes for noteheads etc.), after all LilyPond needs at least one font to base its code on. So what is the point of including more *as part of the code base*? This isn't meant as any kind of argument against or questioning of the request to add another font, I just don't understand what the purpose would be, other than 'because we can'. My only concern is that we then need to include these new fonts (if applicable) as part of the regression test suite surely? And make sure that LilyPond's spacing calculations are not going to be compromised by the addition of new fonts and that it isn't going to start to create more exceptions because one font's dynamic 'f' happens to be wider or fatter than LilyPond's (if you see what I am getting at). Regards James Actually that's what I mean. I suggest to add the _ability_ to easily change the notation font through the make-pango-tree approach and let the user install additional fonts at will. As said this is the same as with any other (notation or any other) program. Of course you expect your word processor to let you choose from arbitrary fonts, but you're completely OK with installing fonts yourself. Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
