Re: SMuFL Adoption
Le 12/02/2021 à 18:53, Jean Abou Samra a écrit : Le 12/02/2021 à 16:48, Garap Magu a écrit : Dear LilyPond Users, Hello, I had a question about Lilypond input files. I saw on the Google Summer of Code page that SMuFL adoption was planned. Would this change the syntax of Lilypond input files? I’m new to Lilypond and am not familiar with what SMuFL adoption would mean to end users. Thank you in advance for any information you may be able to provide. Best, Parag — Parag Magunia https://lilypond.org/google-summer-of-code.html Hello, SMuFL support would not change input syntax. It is about allowing the use of many alternative music notation fonts that follow this standard. There was a blog post on Scores of Beauty explaining the project; unfortunately that website is down at the moment. Meanwhile, you can read lilypond.org/google-summer-of-code.html In CC is Owen Lamb, the student who undertook this effort. Regards, Jean (Whoops, now with Owen actually CCed...)
Re: SMuFL Adoption
Le 12/02/2021 à 16:48, Garap Magu a écrit : Dear LilyPond Users, Hello, I had a question about Lilypond input files. I saw on the Google Summer of Code page that SMuFL adoption was planned. Would this change the syntax of Lilypond input files? I’m new to Lilypond and am not familiar with what SMuFL adoption would mean to end users. Thank you in advance for any information you may be able to provide. Best, Parag — Parag Magunia https://lilypond.org/google-summer-of-code.html Hello, SMuFL support would not change input syntax. It is about allowing the use of many alternative music notation fonts that follow this standard. There was a blog post on Scores of Beauty explaining the project; unfortunately that website is down at the moment. Meanwhile, you can read lilypond.org/google-summer-of-code.html In CC is Owen Lamb, the student who undertook this effort. Regards, Jean
Re: SMuFL Bravura
On Tue, Apr 2, 2019 at 3:06 AM Malte Meyn wrote: > > > Am 01.04.19 um 21:12 schrieb Urs Liska: > > I fully agree with all of that, but I think what Johan wanted to say is > that we should *first* work towards DMuFL compliance before spending > manpower on Emmentaler extensions. > > Which I think is true and not. If there is someone willing to spend > efforts adding stuff to Emmentaler that's a great thing and shouldn't be > discouraged because we have even more pressing things to do. > > That sounds reasonable. And maybe I should try to make some > contributions for SMuFL (renaming and rearranging glyphs should be not > too hard). But that probably should wait until the release of 2.20.0 and > 2.21.0, shouldn’t it? > I have been following this; but I do not know the interests of LilyPond.A code point is a name, changing the name defeats the purpose of SMuFL.SMuFL is in it early stages with more sambals and alternates being added that would have to be rename as they come about. It seems to me that the LilyPond name and the SMuFL codepoint (name) could be combined in some sort of OR statement allowing both. ƒg > > ___ > lilypond-user mailing list > lilypond-user@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-user > ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL Bravura
Am 02.04.19 um 09:48 schrieb Malte Meyn: Am 02.04.19 um 09:34 schrieb Urs Liska: But that probably should wait until the release of 2.20.0 and 2.21.0, shouldn’t it? I don't think so. Of course such a fundamental change doesn't belong in 2.20, but adding stuff to the development branch doesn't seem problematic to me. If it should turn out that starting with these changes imposes any risk of breaking stuff we could still work on a branch for a longer time (and maybe merge that to 2.21 after a 2.20 release). An extra branch is a good idea. I thought of people who want to use the new features introduced in 2.21.0 but not 2.20.0 (there probably will be a lot of those), therefore I’d add changes to master only after the release of 2.21.0 (i. e. 2.21.1 would be the earliest possible release for big SMuFL changes). Ah that's why you asked. No, adding stuff to the development branch will *not* go into 2.20 anymore, that has already been forked. For any new commits to be included in 2.20 David Kastrup would have to manually pick them (which would simply not be done in this case). Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL Bravura
Am 02.04.19 um 09:34 schrieb Urs Liska: But that probably should wait until the release of 2.20.0 and 2.21.0, shouldn’t it? I don't think so. Of course such a fundamental change doesn't belong in 2.20, but adding stuff to the development branch doesn't seem problematic to me. If it should turn out that starting with these changes imposes any risk of breaking stuff we could still work on a branch for a longer time (and maybe merge that to 2.21 after a 2.20 release). An extra branch is a good idea. I thought of people who want to use the new features introduced in 2.21.0 but not 2.20.0 (there probably will be a lot of those), therefore I’d add changes to master only after the release of 2.21.0 (i. e. 2.21.1 would be the earliest possible release for big SMuFL changes). ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL Bravura
Am 02.04.19 um 09:05 schrieb Malte Meyn: Am 01.04.19 um 21:12 schrieb Urs Liska: I fully agree with all of that, but I think what Johan wanted to say is that we should *first* work towards DMuFL compliance before spending manpower on Emmentaler extensions. Which I think is true and not. If there is someone willing to spend efforts adding stuff to Emmentaler that's a great thing and shouldn't be discouraged because we have even more pressing things to do. That sounds reasonable. And maybe I should try to make some contributions for SMuFL (renaming and rearranging glyphs should be not too hard). I don't really know how that works internally. But since LilyPond calls glyphs by name while SMuFL looks at code points (is that correct?) I can imagine it should be quite straightforward to get to a point (as a first step) where LilyPond doesn't notice the change while SMuFL-compliant applications can find the glyphs where *they* expect them. Maybe it is a good idea to go for that first, completely ignoring the font metrics because (as far as I understand how it works) that will be trickier, more involved and probably somewhat tedious. But that probably should wait until the release of 2.20.0 and 2.21.0, shouldn’t it? I don't think so. Of course such a fundamental change doesn't belong in 2.20, but adding stuff to the development branch doesn't seem problematic to me. If it should turn out that starting with these changes imposes any risk of breaking stuff we could still work on a branch for a longer time (and maybe merge that to 2.21 after a 2.20 release). Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL Bravura
Am 01.04.19 um 21:12 schrieb Urs Liska: I fully agree with all of that, but I think what Johan wanted to say is that we should *first* work towards DMuFL compliance before spending manpower on Emmentaler extensions. Which I think is true and not. If there is someone willing to spend efforts adding stuff to Emmentaler that's a great thing and shouldn't be discouraged because we have even more pressing things to do. That sounds reasonable. And maybe I should try to make some contributions for SMuFL (renaming and rearranging glyphs should be not too hard). But that probably should wait until the release of 2.20.0 and 2.21.0, shouldn’t it? ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL Bravura
Am 1. April 2019 20:07:47 MESZ schrieb Malte Meyn : > > >Am 01.04.19 um 12:01 schrieb Johan Vromans: >> On Mon, 1 Apr 2019 09:17:26 +0200, Malte Meyn >wrote: >> >>> SMuFL integration and using Metafont for glyph creation don’t >>> contradict, do they? >> >> They do, in so far that with limited resources you cannot do both. > >[sending on-list, sorry Johan for the double post] > >What do you mean by “limited resources”? A lack of manpower? I don’t >think it’s a real problem: > >“In order for a font to be considered SMuFL-compliant, it should >implement as many of the recommended characters as are appropriate for >the intended use of the font, at the specified code points. Fonts need >not implement every recommended character, and need not implement any >optional glyphs, in order to be considered SMuFL-compliant.” (SMuFL >specification >https://w3c.github.io/smufl/gitbook/about/recommended-chars-optional-glyphs.html) > >I think that means that Emmentaler could be made SMuFL-compliant >without >having to add any characters: The intended use of Emmentaler is to work > >with LilyPond as it will have done before SMuFL-compliance. Of course, >once this is done, additions can be made. But there is no need of new >Metafont code for SMuFL-compliance so I don’t think we should abandon >Metafont. > I fully agree with all of that, but I think what Johan wanted to say is that we should *first* work towards DMuFL compliance before spending manpower on Emmentaler extensions. Which I think is true and not. If there is someone willing to spend efforts adding stuff to Emmentaler that's a great thing and shouldn't be discouraged because we have even more pressing things to do. Urs >___ >lilypond-user mailing list >lilypond-user@gnu.org >https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL Bravura
Am 01.04.19 um 12:01 schrieb Johan Vromans: On Mon, 1 Apr 2019 09:17:26 +0200, Malte Meyn wrote: SMuFL integration and using Metafont for glyph creation don’t contradict, do they? They do, in so far that with limited resources you cannot do both. [sending on-list, sorry Johan for the double post] What do you mean by “limited resources”? A lack of manpower? I don’t think it’s a real problem: “In order for a font to be considered SMuFL-compliant, it should implement as many of the recommended characters as are appropriate for the intended use of the font, at the specified code points. Fonts need not implement every recommended character, and need not implement any optional glyphs, in order to be considered SMuFL-compliant.” (SMuFL specification https://w3c.github.io/smufl/gitbook/about/recommended-chars-optional-glyphs.html) I think that means that Emmentaler could be made SMuFL-compliant without having to add any characters: The intended use of Emmentaler is to work with LilyPond as it will have done before SMuFL-compliance. Of course, once this is done, additions can be made. But there is no need of new Metafont code for SMuFL-compliance so I don’t think we should abandon Metafont. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL Bravura
On Mon 01 Apr 2019 at 09:16:24 (+0200), David Kastrup wrote:
> David Wright writes:
> > On Mon 01 Apr 2019 at 11:37:42 (+1100), Andrew Bernard wrote:
> >> Hi Valentin,
> >>
> >> Thanks so much. Now to learn Metafont then. Shouldn't be too hard - I have
> >> been a programmer for more than forty years. [Despite that, I still cannot
> >> come to grips with the lilypond source, and all my lilypond questions all
> >> appear to be from a beginner. :-) ]
> >>
> >> The immediate task is to add various violin string mute symbols. But it
> >> sounds like this is going to be a useful skill to have.
> >
> > Don't miss the book at [deleted]
>
> The METAFONT book is copyrighted, and distribution of the PDF certainly
> is a violation of the copying permissions for its source code which has
> been made available for educational permissions with the following
> notice/code at the start:
I hadn't realised that this book hadn't been made available under the
GFDL, like a fair number of books of this vintage. I was also fooled
(appropriate date) by the site. CTEX ≢ CTAN.
> % This manual is copyright (C) 1986 by the American Mathematical Society.
> % All rights are reserved!
> % The file is distributed only for people to see its examples of TeX input,
> % not for use in the preparation of books like The METAFONTbook.
> % Permission for any other use of this file must be obtained in writing
> % from the copyright holder and also from the publisher (Addison-Wesley).
> \let\MFmanual=\!
> \loop\iftrue
> \errmessage{This manual is copyrighted and should not be TeXed}\repeat
>
> I don't think you are doing people a favor by pointing them to PDF files
> created in defiance of the license, discouraging the publisher from
> being similarly helpful in future.
I hadn't read the source code itself from CTAN.
Cheers,
David.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL Bravura
On Mon, 1 Apr 2019 09:17:26 +0200, Malte Meyn wrote: > SMuFL integration and using Metafont for glyph creation don’t > contradict, do they? They do, in so far that with limited resources you cannot do both. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL Bravura
David Wright writes:
> On Mon 01 Apr 2019 at 11:37:42 (+1100), Andrew Bernard wrote:
>> Hi Valentin,
>>
>> Thanks so much. Now to learn Metafont then. Shouldn't be too hard - I have
>> been a programmer for more than forty years. [Despite that, I still cannot
>> come to grips with the lilypond source, and all my lilypond questions all
>> appear to be from a beginner. :-) ]
>>
>> The immediate task is to add various violin string mute symbols. But it
>> sounds like this is going to be a useful skill to have.
>
> Don't miss the book at
> http://www.ctex.org/documents/shredder/src/mfbook.pdf
The METAFONT book is copyrighted, and distribution of the PDF certainly
is a violation of the copying permissions for its source code which has
been made available for educational permissions with the following
notice/code at the start:
% This manual is copyright (C) 1986 by the American Mathematical Society.
% All rights are reserved!
% The file is distributed only for people to see its examples of TeX input,
% not for use in the preparation of books like The METAFONTbook.
% Permission for any other use of this file must be obtained in writing
% from the copyright holder and also from the publisher (Addison-Wesley).
\let\MFmanual=\!
\loop\iftrue
\errmessage{This manual is copyrighted and should not be TeXed}\repeat
I don't think you are doing people a favor by pointing them to PDF files
created in defiance of the license, discouraging the publisher from
being similarly helpful in future.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL Bravura
Am 01.04.19 um 08:59 schrieb Johan Vromans: On Mon, 1 Apr 2019 11:37:42 +1100, Andrew Bernard wrote: Now to learn Metafont then. Shouldn't be too hard - As a retired TeXnician I have deep respect for TeX and MetaFont. Nevertheless I think the right way now is to go for widely accepted standards where possible. So I'd rather see decent SMuFL integration than more home grown Emmentaler extensions. SMuFL integration and using Metafont for glyph creation don’t contradict, do they? Of course we should concentrate on glyphs requested by SMuFL instead of “home grown” symbols. But why not use Metafont for that? And if someone misses a glyph in Emmentaler that is not in SMuFL one should make an enhancement request (https://github.com/w3c/smufl/issues or https://lists.w3.org/Archives/Public/public-music-notation-contrib/) Of course we would have to rename the Emmentaler glyphs and have a script that puts them at the correct code points in the font. And we would have to look at the specification (https://w3c.github.io/smufl/gitbook/specification/) for glyph metrics, ligatures etc. Probably when metrics change there have to be changes in the LilyPond source code too … ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL Bravura
Hi Andrew and Johan, Am 01.04.19 um 08:59 schrieb Johan Vromans: On Mon, 1 Apr 2019 11:37:42 +1100, Andrew Bernard wrote: Now to learn Metafont then. Shouldn't be too hard - As a retired TeXnician I have deep respect for TeX and MetaFont. Nevertheless I think the right way now is to go for widely accepted standards where possible. So I'd rather see decent SMuFL integration than more home grown Emmentaler extensions. I wanted to join this discussion although my comments had already become separate from the direction of the discussion, but your comment gives me a good opportunity. These are two separate discussions, and I think SMuFL integration is not opposed to extending Emmentaler and to using the Metafont approach in the first place. As has been pointed out currently SMuFL fonts such as Bravura can only be used with a compatibility layer and actually using the fonts in a non-native way. When Bravura is only wanted for its font design there is a working clone by Abraham that can be used. SMuFL integration doesn't seem to be very high on our priority list, but I think it is by now accepted that changing LilyPond's font handling to be SMuFL compliant would be a good thing to have. That's why we even have a GSoC project suggestion for it: http://lilypond.org/google-summer-of-code.html#Adopt-the-SMuFL-music-font-encoding-standard. Making LilyPond's font handling compatible to using SMuFL fonts would not mean that Emmentaler can't still be created from Metafont sources. Andrew: Maybe having a look at that project would also be an option for you? (Considering that chances we'll have a student working on it through GSoC are definitely below 50%) It might even be an opportunity to get familiar with how things work ... Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL Bravura
Aaron Hill writes: > On 2019-03-31 6:14 pm, edes wrote: >> el 2019-04-01 a las 11:37 Andrew Bernard escribió: >> >>> Thanks so much. Now to learn Metafont then. Shouldn't be too hard >> >> unlike valentin, i admire you already even if you don't succeed. i >> don't >> know what admire the most: the determination of the "now to learn >> metafont", or the optimism of the "shouldn't be too hard". i'm sure >> all of >> us are wishing you the best of luck. > > I gave Metafont a casual, first glance a number of months ago. It did > not seem that difficult, although I am sure it has its fair share of > idiosyncrasies that I simply have not yet encountered. > > One of Metafont's strengths as a tool is that each glyph is described > programmatically. More like analytically. One of the idiosyncrasies of Metafont is that you usually describe the relations of the curves with equations rather than assignments and Metafont then solves the equations. It does not make a difference between x = 7 and 7 = x It does have assignments ( := ) which work by first eliminating the variable on the left-hand side as well as it can from existing equations, then detaching it and then creating a new equation. Also its expression machinery is designed around describing paths by tracing semi-elliptical pencil outlines along cubic B-spline paths. > I am not sure how complex the various articulations are that Andrew > needs to add. Assuming there is an existing glyph that is close but > needs some tweaking, it should be fairly straightforward to adapt > current code to the new glyph. Imitation is the best form of flattery, yes. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL Bravura
On Mon, 1 Apr 2019 11:37:42 +1100, Andrew Bernard wrote: > Now to learn Metafont then. Shouldn't be too hard - As a retired TeXnician I have deep respect for TeX and MetaFont. Nevertheless I think the right way now is to go for widely accepted standards where possible. So I'd rather see decent SMuFL integration than more home grown Emmentaler extensions. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL Bravura
On 2019-03-31 6:14 pm, edes wrote: el 2019-04-01 a las 11:37 Andrew Bernard escribió: Thanks so much. Now to learn Metafont then. Shouldn't be too hard unlike valentin, i admire you already even if you don't succeed. i don't know what admire the most: the determination of the "now to learn metafont", or the optimism of the "shouldn't be too hard". i'm sure all of us are wishing you the best of luck. I gave Metafont a casual, first glance a number of months ago. It did not seem that difficult, although I am sure it has its fair share of idiosyncrasies that I simply have not yet encountered. One of Metafont's strengths as a tool is that each glyph is described programmatically. Consider when you want to have a font with a variety of weights. Rather than author each weight independently, Metafont lets you describe glyphs in general terms, where the target weight is simply an input parameter. This process is admittedly more abstract than just drawing the outline of each glyph by hand; but it certainly becomes much more productive in the long-run. As folks might already know, Lilypond's font comes in specific versions for different target point sizes as to maintain a more consistent look and feel to the shapes. If you were to simply scale up or scale down a glyph, then details can become too rounded or too sharpened compared to other details. Here again is where Metafont helps. The general outline of a glyph is described in code where things like the size and shape of the virtual pen can be controlled parametrically. I am not sure how complex the various articulations are that Andrew needs to add. Assuming there is an existing glyph that is close but needs some tweaking, it should be fairly straightforward to adapt current code to the new glyph. -- Aaron Hill ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL Bravura
On Mon 01 Apr 2019 at 11:37:42 (+1100), Andrew Bernard wrote: > Hi Valentin, > > Thanks so much. Now to learn Metafont then. Shouldn't be too hard - I have > been a programmer for more than forty years. [Despite that, I still cannot > come to grips with the lilypond source, and all my lilypond questions all > appear to be from a beginner. :-) ] > > The immediate task is to add various violin string mute symbols. But it > sounds like this is going to be a useful skill to have. Don't miss the book at http://www.ctex.org/documents/shredder/src/mfbook.pdf I assume that font production is much the same as here, though the way in which fonts are then handled may well have changed a lot. Cheers, David. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL Bravura
el 2019-04-01 a las 11:37 Andrew Bernard escribió: > Thanks so much. Now to learn Metafont then. Shouldn't be too hard unlike valentin, i admire you already even if you don't succeed. i don't know what admire the most: the determination of the "now to learn metafont", or the optimism of the "shouldn't be too hard". i'm sure all of us are wishing you the best of luck. -- ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL Bravura
Hi Valentin, Thanks so much. Now to learn Metafont then. Shouldn't be too hard - I have been a programmer for more than forty years. [Despite that, I still cannot come to grips with the lilypond source, and all my lilypond questions all appear to be from a beginner. :-) ] The immediate task is to add various violin string mute symbols. But it sounds like this is going to be a useful skill to have. Andrew On Mon, 1 Apr 2019 at 01:50, Valentin Villenave wrote: > > Very extensible; quite a few new glyphs have been added recently. > That is, however, assuming you can master metafont syntax. Many have > given up, but you’ll be regarded as a hero if you do -- well, at least > by me :-) > > ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL Bravura
On 3/31/19, Andrew Bernard wrote: > To the point, I want some various string mute symbols. Would it be better > for me to look into adding glyphs to Emmentaler with metafont? How > extensible is Emmentaler? Very extensible; quite a few new glyphs have been added recently. That is, however, assuming you can master metafont syntax. Many have given up, but you’ll be regarded as a hero if you do -- well, at least by me :-) Using SMuFL with LilyPond requires but a thin compatibility layer (mainly because of different glyph name mapping); that’s what the OpenLily thingamabob does and it should be rather useable even with recent LilyPond builds. (I wish it wasn’t implemented in that way, but that’s how things are for now.) Otherwise, you may or may not be better off with simple postscript or svg markups, e.g. http://lsr.di.unimi.it/LSR/Item?id=1085 Cheers, V. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Zitat von Janek Warchoł janek.lilyp...@gmail.com: Hi folks, 2013/8/9 Urs Liska u...@openlilylib.org: Hi all, although I suspect this could once more become a longish and scattered thread, I feel forced to bring it up here. What do you think: would it make sense to open up LilyPond thinking to the idea of SMuFL brought up by Steinberg and Daniel Spreadbury? http://www.smufl.org Of course currently it's only their new Bravura font that complies to that proposed standard. But I can imagine there will be more 'participators' in mid-term future. Any thoughts? I've missed the main discussion but i have a (hopefully) valuable comment. We don't know if it would be worth it to make LilyPond support SMuFL. But i think the question is: what should we do to make it easier to us to adopt SMuFL if we decide to to do in the future? In other words, how can we influence SMuFL design so that it would fit LilyPond better (without doing anything ourselves). For example, it would probably be a good idea to ensure that SMuFL has places for all glyphs we have. I think that's the least we should try to achieve. Otherwise we'd risk getting left behind if SMuFL turns out to become an accepted standard. And although we don't know that yet, I think chances are not too bad that this may happen. Daniel Spreadbury wrote to me: It would definitely be useful to have a list of gaps between SMuFL and the Emmentaler font. I have looked at the Emmentaler documentation a little bit, but I haven't necessarily understood everything that's in there. There are some early music-specific ranges, for example, that I would need to be able to consult with a subject area expert before I could consider encoding them in SMuFL. One additional suggestion would be to move Emmentaler's glyphs to the Unicode codepoints suggested by SMuFL. IIUC this wouldn't need any internal change in the layout engine at first. And in the process of remapping any gaps would become apparent 'automatically'. I think there even is someone here who would be willing to look into it - if he gets any positive feedback from the community. Urs best, Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Hi, 2013/8/18 u...@openlilylib.org: Zitat von Janek Warchoł janek.lilyp...@gmail.com: We don't know if it would be worth it to make LilyPond support SMuFL. But i think the question is: what should we do to make it easier to us to adopt SMuFL if we decide to to do in the future? In other words, how can we influence SMuFL design so that it would fit LilyPond better (without doing anything ourselves). For example, it would probably be a good idea to ensure that SMuFL has places for all glyphs we have. I think that's the least we should try to achieve. Otherwise we'd risk getting left behind if SMuFL turns out to become an accepted standard. And although we don't know that yet, I think chances are not too bad that this may happen. One additional suggestion would be to move Emmentaler's glyphs to the Unicode codepoints suggested by SMuFL. IIUC this wouldn't need any internal change in the layout engine at first. And in the process of remapping any gaps would become apparent 'automatically'. I think there even is someone here who would be willing to look into it - if he gets any positive feedback from the community. I can help with this - i don't have time to get fully engaged, but if there will be a volunteer and he runs into trouble, i will do my best to help him. cheers Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Hi, a short comment: 2013/8/11 David Kastrup d...@gnu.org: Werner LEMBERG w...@gnu.org writes: I think so poorly documented that in practice almost no one can understand how it works still can't qualify as in effect proprietary. It is not *that* badly documented. However, the number of people who understand Metafont are rather small today. git shortlog -sn mf/ 459 Han-Wen Nienhuys 160 Jan Nieuwenhuizen 104 Werner Lemberg 20 Jürgen Reuter 16 Carl D. Sorensen 15 Janek Warchoł 11 Mats Bengtsson 7 Bertrand Bordage 7 Maximilian Albert 4 David Kastrup 4 Graham Percival 4 John Mandereau 4 Phil Holmes 4 Tom Cato Amundsen 3 Erlend Aasland 3 Marc Hohl 3 Patrick McCarty 3 Reinhold Kainhofer 3 Rune Zedeler 2 Aleksandr Andreev 2 Neil Puttock 1 Benkő Pál 1 Carsten Steger 1 Glen Prideaux 1 Julien Rioux 1 Mark Polesky 1 Michael Welsh Duggan 1 Nicolas Sceaux Some of those will have worked on the build system rather than the fonts themselves, but I doubt that all of those working on the fonts had previous exposure to Metafont/Metapost. All my commits concerned Metafont, but i would never say that i *understand* Metafont. I was just juggling with some numbers, trying like monkey until it worked. And as i'm pretty high on the list, this really means that few people understand Metafont. Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Hi folks, 2013/8/9 Urs Liska u...@openlilylib.org: Hi all, although I suspect this could once more become a longish and scattered thread, I feel forced to bring it up here. What do you think: would it make sense to open up LilyPond thinking to the idea of SMuFL brought up by Steinberg and Daniel Spreadbury? http://www.smufl.org Of course currently it's only their new Bravura font that complies to that proposed standard. But I can imagine there will be more 'participators' in mid-term future. Any thoughts? I've missed the main discussion but i have a (hopefully) valuable comment. We don't know if it would be worth it to make LilyPond support SMuFL. But i think the question is: what should we do to make it easier to us to adopt SMuFL if we decide to to do in the future? In other words, how can we influence SMuFL design so that it would fit LilyPond better (without doing anything ourselves). For example, it would probably be a good idea to ensure that SMuFL has places for all glyphs we have. best, Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Hello, When changing font in text processing, you switch to a different font, and most time that's it. Relative placement is taken care of by the provided font metrics. In music notation there is a font, but at least within Lilipond objects like staves are draws not using glyphs from fonts but more primitive graphics objects. So I feel one should also change the layout of quite a few graphical objects when switching fonts. I wonder whether one would call that layout or style. In the current SMuFL paper (Version 0.4) there are some options: use complete notes as provided, or assemble from notehead, stem and flag ? is there some guidance how to match stem height to flag for best visual appearance ? use complete brackets, or assemble (and combine with a non-font line) ? What line thickness to go with U+E003 / U+E004 ? ? Should there be a vertical line in the font with such thickness ? use the staves (with the line thickness as provided) or draw lines While Scoring programs should draw their own staff lines using primitives ? does the font tell you what the line thickness should be ? So how to package this ancillary information to go with a font? Regards Klaus ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Klaus Föhl klaus.fo...@uni-giessen.de writes: Hello, When changing font in text processing, you switch to a different font, and most time that's it. Relative placement is taken care of by the provided font metrics. In music notation there is a font, but at least within Lilipond objects like staves are draws not using glyphs from fonts but more primitive graphics objects. So I feel one should also change the layout of quite a few graphical objects when switching fonts. I wonder whether one would call that layout or style. In the current SMuFL paper (Version 0.4) there are some options: use complete notes as provided, or assemble from notehead, stem and flag ? is there some guidance how to match stem height to flag for best visual appearance ? use complete brackets, or assemble (and combine with a non-font line) ? What line thickness to go with U+E003 / U+E004 ? ? Should there be a vertical line in the font with such thickness ? use the staves (with the line thickness as provided) or draw lines While Scoring programs should draw their own staff lines using primitives ? does the font tell you what the line thickness should be ? So how to package this ancillary information to go with a font? This question has been a problem essentially forever, even from before computers - clefs and brackets are often engraved separately from notes, etc. Some computer music typesetting software has essentially declared Everything we print is a character in a font, even staff lines. Other software has gone in other directions. In the context of good typesetting, the answer is It doesn't really matter, just do the best most efficient job possible. I think, in the context of Lilypond, the best answer is Package the information in such a way that the creator of a new Lilypond font will be able to understand what he needs to do without having to navigate Lilypond internals or know how the typesetting works. Or, to put it another way, the document How to Create a Lilypond Music Font should ideally be short, and able to be understood and successfully applied by someone who knows fonts but doesn't know Lilypond. Right now, such a font person tries to make a Lilypond font, gets quite some way into the work, and finds these few lines buried in the documentation: Step 893: Re-write Lilypond to accommodate what you've created in the preceding 892 steps. This step is left as an exercise for the reader. Step 894: If you are religious, you should take some time to pray now. Even if you're not religious, praying is still recommended, just in case. Step 895: I thought that might happen. Too bad. Oh well, go back to Step 1 and let's try to see what went wrong. :) I have no illusion that making a font for Lilypond should be easy. I _do_ have the illusion that it ought to be a clearly-defined task.* If, in Lilypond's case, Font means more than it does in other situations (for example, if for Lilypond a font designer must provide a lot of additional measurements or extra glyphs), well, so be it. As long as he's told what the requirements are, and how to ensure that his new font will actually work. * - It's easy to see that the history of Lilypond development might have meant that at one time there was a lot of pressure to get it working and very little pressure or desire to get it ready for different music fonts. -- David R ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Carl Peterson carlopeter...@gmail.com writes: I think we're getting hung up on the fact that SMuFL is being promulgated by a corporate entity and the only implementation of SMuFL is produced by that corporate entity (and that most of the musical font work is being done by other corporate entities releasing them under proprietary licenses). Am I the only one to interpret SMuFL as *Steinberg* Music Font Layout? What is missing from the SMuFL information is an impressive list of music software that backs up SMuFL. I think we can wait until competing non-Steinberg music software is picking up support for SMuFL. Waiting for broad support does not mean that it won't be good to start thinking how LilyPond font handling can benefit from a SMuFL(-like) approach. -- Johan ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Johan Vromans jvrom...@squirrel.nl schrieb: Carl Peterson carlopeter...@gmail.com writes: I think we're getting hung up on the fact that SMuFL is being promulgated by a corporate entity and the only implementation of SMuFL is produced by that corporate entity (and that most of the musical font work is being done by other corporate entities releasing them under proprietary licenses). Am I the only one to interpret SMuFL as *Steinberg* Music Font Layout? What is missing from the SMuFL information is an impressive list of music software that backs up SMuFL. That's the question. Of course at this point of time we can't expect any list to be existent. I think we can wait until competing non-Steinberg music software is picking up support for SMuFL. Of course, but what if everybody thinks so? Waiting for broad support does not mean that it won't be good to start thinking how LilyPond font handling can benefit from a SMuFL(-like) approach. That's what we're doing right now. And despite all the controversy I think that's a good thing. Urs -- Johan ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Urs Liska u...@openlilylib.org writes: Johan Vromans jvrom...@squirrel.nl schrieb: Carl Peterson carlopeter...@gmail.com writes: I think we're getting hung up on the fact that SMuFL is being promulgated by a corporate entity and the only implementation of SMuFL is produced by that corporate entity (and that most of the musical font work is being done by other corporate entities releasing them under proprietary licenses). Am I the only one to interpret SMuFL as *Steinberg* Music Font Layout? What is missing from the SMuFL information is an impressive list of music software that backs up SMuFL. That's the question. Of course at this point of time we can't expect any list to be existent. I think we can wait until competing non-Steinberg music software is picking up support for SMuFL. Of course, but what if everybody thinks so? People comfortable with proprietary licensing have more to gain than we have. Waiting for broad support does not mean that it won't be good to start thinking how LilyPond font handling can benefit from a SMuFL(-like) approach. That's what we're doing right now. And despite all the controversy I think that's a good thing. So far, I don't see that SMuFL is more than calling a particular choice a standard. You could equally well say why isn't Steinberg picking up the Emmentaler standard?. SMuFL is a font layout. Saying it will be good to start thinking how LilyPond font handling can benefit from a font layout makes precious little sense since obviously we _have_ a font layout. So the question is one of how can LilyPond benefit from supporting _more_ font layouts or how can LilyPond benefit from _changing_ its font layout. Now LilyPond can't even support multiple music fonts with the _same_ font layout. So the first question LilyPond needs to solve is how can we support multiple music fonts. This question does not require SMuFL. We already have the free fonts Gonville and the Jazz font project in need of having this question resolved, and I don't see that we have much to gain by focusing a much more complex question with so far dubious benefits (to put it mildly) when we have not even tackled the simpler question with tangible benefits. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
On 11/08/13 8:09 PM, David Kastrup wrote: So far, I don't see that SMuFL is more than calling a particular choice a standard. You could equally well say why isn't Steinberg picking up the Emmentaler standard?. SMuFL is a font layout. Saying it will be good to start thinking how LilyPond font handling can benefit from a font layout makes precious little sense since obviously we _have_ a font layout. SmuFL is a _proposed_ standard, seeking to gain acceptance if it has merit. I have not seen Emmentaler being proposed as an industry standard (perhaps it has been?) So it goes further than just Steinberg's format for their application. It is being posited as something that can be shared. Obviously there is political benefit in this for Steinberg being seen to be creating and promoting standards, but there is technical benefit as well. I'm aware that lilypond has fairly deep font complexities - isn't that the point, to help unify the approach to music fonts, with one goal in mind of allowing the _engraver_ to have more choice? There is discussion of what is the benefit to lilypond, but shouldn't that be rephrased and cached in terms of what is the benefit to the users of the program? So David, what is the most important area that needs tackling re font handing in lilypond, and where do the main difficulties lie? Why is it so hard to offer more fonts for lilypond? What are the technical obstacles. Andrew ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Am 10.08.2013 10:30, schrieb David Kastrup: Andrew Bernard andrew.bern...@gmail.com 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. 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. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Urs Liska u...@openlilylib.org writes: Am 10.08.2013 10:30, schrieb David Kastrup: Andrew Bernard andrew.bern...@gmail.com 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. That is outside of the scope of the GNU project, however. 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. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Am 11.08.2013 14:43, schrieb David Kastrup: Urs Liska u...@openlilylib.org writes: Am 10.08.2013 10:30, schrieb David Kastrup: Andrew Bernard andrew.bern...@gmail.com 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 ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
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
Re: SMuFL
Am 11.08.2013 15:54, schrieb David Kastrup: Urs Liska u...@openlilylib.org writes: 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. That's what I wanted to stress. More than once in this discussion we had comments that seem to indicate that SMuFL is evil because it allows non-free fonts to be used. 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. As is the idea with SMuFL. As I see it we have three core issues in this discussion. And we seem to be going in circles because of the interdependencies of these three issues: 1) Conceptually it would be acceptable to have LilyPond support SMuFL compliant fonts. 2) An important issue is the relation between advantages such a change would have for commercial vendors vs. free software projects. And their users. A subquestion in this respect is if SMuFL turns out to be/become an 'open' standard. 3) It's currently not really an option to tackle such a change from the technical POV. LilyPond is quite far away from being able to play together with other fonts. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Hi all, 3) It's currently not really an option to tackle such a change from the technical POV. LilyPond is quite far away from being able to play together with other fonts. From my (perhaps naïve) perspective, this seems to be the chicken whence the egg comes. ;) Put another way: If we focused on solving #3 — i.e., fixing Lily so that she DOES play easily/well/perfectly with other fonts — wouldn't we be in a far better position to act on #1 and #2, if it was desirable/feasible/acceptable? And said effort, it seems to me, would not be wasted even if we bailed on SMuFL, and simply made other free (possibly non-SMuFL compliant) fonts a part of the standard Lily distro. Am I wrong there? Thanks, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Urs Liska u...@openlilylib.org writes: As I see it we have three core issues in this discussion. And we seem to be going in circles because of the interdependencies of these three issues: More like because people don't listen and instead of addressing an argument bring up something else again since there is more than one issue involved. 1) Conceptually it would be acceptable to have LilyPond support SMuFL compliant fonts. Supporting something is not the question. The question is whether there are efforts needed _specifically_ to support only hypothetical or non-free fonts. That question is rendered moot by the existence of a freely licensed Bravura font though the jury is out on just how usable it may be at the current point of time. 2) An important issue is the relation between advantages such a change would have for commercial vendors vs. free software projects. And their users. No, not really. The relation is not interesting. The only question the LilyPond project as such needs to concern itself with is what advantages and disadvantages does this have for using LilyPond in the context of free software. Whether or not proprietary projects and their users benefit is not an issue either way. We do not want to make it harder to use or maintain LilyPond with free fonts. That's all. 3) It's currently not really an option to tackle such a change from the technical POV. LilyPond is quite far away from being able to play together with other fonts. Yes. There is no point in thinking about switching between fonts with a different layout when we can't even switch between fonts using the same layout. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Kieren MacMillan kieren_macmil...@sympatico.ca writes: Hi all, 3) It's currently not really an option to tackle such a change from the technical POV. LilyPond is quite far away from being able to play together with other fonts. From my (perhaps naïve) perspective, this seems to be the chicken whence the egg comes. ;) Put another way: If we focused on solving #3 — i.e., fixing Lily so that she DOES play easily/well/perfectly with other fonts — wouldn't we be in a far better position to act on #1 and #2, if it was desirable/feasible/acceptable? By the time #3 is finished, the perspective on the other points might be clearer. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Thanks Werner for pointing this out. It would help if I read the SMuFL standard before commenting. :-) So I think my previous comments are invalid. Now that I have read the standard v 0.6, I see that it works hand in hand with Unicode, and is not in opposition to, or outside of Unicode. Given that SMuFL defines the Unicode code points for a much larger set of glyphs for music - and can be almost limitlessly expanded - than the current Unicode musical symbol set, and that Unicode is a very widely respected standard, would it not be the to go to have lilypond use the SMuFL standard for its fonts, and not to make a mapping between SMuFL and the current Emmentaler layout? Would this be a major or difficult internal change in the codebase? 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. Andrew On 10/08/13 2:21 PM, Werner LEMBERG wrote: I disagree, and I think that you are completely missing the purpose of SMuFL: It collects *glyphs* which are used somewhere, and which people need somehow. Compare this to the Adobe Glyph Collections like `Adobe-Korea1-2' or `Adobe-GB1-5'. As they write on smufl.org: The goal of SMuFL is to establish a new standard glyph mapping for musical symbols that is optimised for OpenType fonts and that can be adopted by a variety of software vendors and font designers, for the benefit of all users of music notation software. Unicode is a *character* standard, mainly to *exchange* information. It is *not* related to glyphs, or to fonts. The SMuFL team correctly maps the glyphs to the Private Area of Unicode, and they don't suggest the inclusion of any of those entities into the Unicode standard. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Andrew Bernard andrew.bern...@gmail.com 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? Think again. What's in it for them? The LilyPond fonts. Basically they are saying if you do all the work to convert the LilyPond fonts to the layout and metrics that our software happens to use, then in return thank you very much. So far I see it mostly as a way to increase their market value. If you buy their software and fonts in order to be able to use their software with LilyPond's fonts, they get money for fonts people don't want to use. If you buy their software and fonts in order to be able to use their fonts with LilyPond's software, they get money for software people don't want to use. Of course, it's not just LilyPond that is in the game here: all of the commercial vendors win if the preferred setup of customers requires buying three different complete music software suites from different vendors, utilizing only a third of each. But if we are focusing on our core mission to provide _free_ software, what do we get in return for our cooperation? Puzzling problems and bug reports for setups which are only half under our own control. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Interesting valid points David. But I was thinking that it although lilypond is open source, why can't I purchase _commercial_ music fonts to use with it, just as one does for print typesetting? I did not see the fonts as being tied to buying the engraving software, but a decoupled market. I can see music system vendors selling fonts just like Adobe does. And why can't future Steinberg users incorporate lilypond fonts? After all, lilypond is open source and we are encouraging people to have it for free, work with it, extend it and nurture it. Or are the open source licensing restrictions that prevent lilypond components such as fonts being utilised by commercial software (I don't know)? And I think you can download Steinberg Bravura font presently for free, although I understand this is principally as a reference font implementation for SMuFL. Andrew On 10/08/13 6:30 PM, David Kastrup wrote: 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? ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Am 10.08.2013 10:52, schrieb Andrew Bernard: Interesting valid points David. But I was thinking that it although lilypond is open source, why can't I purchase _commercial_ music fonts to use with it, just as one does for print typesetting? I did not see the fonts as being tied to buying the engraving software, but a decoupled market. I can see music system vendors selling fonts just like Adobe does. And why can't future Steinberg users incorporate lilypond fonts? After all, lilypond is open source and we are encouraging people to have it for free, work with it, extend it and nurture it. Or are the open source licensing restrictions that prevent lilypond components such as fonts being utilised by commercial software (I don't know)? And I think you can download Steinberg Bravura font presently for free, although I understand this is principally as a reference font implementation for SMuFL. Andrew On 10/08/13 6:30 PM, David Kastrup wrote: 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? Of course this is all quite complex and difficult. One thought: Of course you can buy commercial fonts and use them with LaTeX. But the free TeX distros won't for example packages that are macros supporting non-free fonts. Although I personally would like to have the option to use proprietary fonts with LilyPond. Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Greetings List, On 10/08/13 6:57 PM, Urs Liska wrote: Of course this is all quite complex and difficult. Which is why this discussion thread is important, I reckon. One thought: Of course you can buy commercial fonts and use them with LaTeX. I use commercial fonts with the open source ConTeXT program. But the free TeX distros won't for example packages that are macros supporting non-free fonts. Can you explain that more? Although I personally would like to have the option to use proprietary fonts with LilyPond. Not proprietary, but SMuFL fonts, commercially packaged! :-) Emmentaler is, in effect, proprietary, although free. Andrew ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Andrew Bernard andrew.bern...@gmail.com writes: Interesting valid points David. But I was thinking that it although lilypond is open source, why can't I purchase _commercial_ music fonts to use with it, just as one does for print typesetting? Because they are not standardized. At any rate, it's not much of a priority for a free software project to make it easier to use proprietary software. And why can't future Steinberg users incorporate lilypond fonts? They can: they are released under both GPL and SIL. But why should they expect us to do the work needed to make proprietary software more competitive? After all, lilypond is open source and we are encouraging people to have it for free, work with it, extend it and nurture it. And contribute back. That's why LilyPond is under a Copyleft license in the first place. So what's the contribution back that we can expect? Of course, people are free to do whatever they want with their own time and efforts. But if you do it out of a feeling of contributing to LilyPond, it may be worth looking quite closer before investing a lot of effort. You might also be disappointed in the lack of uptake by the LilyPond websites, manuals and other resources for proprietary font support. URL:http://www.gnu.org/prep/maintain/maintain.html#Ethical-and-Philosophical-Consideration states: A GNU package should not recommend use of any non-free program, nor should it require a non-free program (such as a non-free compiler or IDE) to build. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
On 10/08/13 7:10 PM, David Kastrup wrote: Andrew Bernard andrew.bern...@gmail.com writes: Interesting valid points David. But I was thinking that it although lilypond is open source, why can't I purchase _commercial_ music fonts to use with it, just as one does for print typesetting? Because they are not standardized. At any rate, it's not much of a priority for a free software project to make it easier to use proprietary software. I was not clear. What I meant was, if SMuFL does become an accepted standard, then fonts could be standardised, and then we could use them if lilypond adopted SMuFL. After all, lilypond is open source and we are encouraging people to have it for free, work with it, extend it and nurture it. And contribute back. That's why LilyPond is under a Copyleft license in the first place. So what's the contribution back that we can expect? A wider range of choice of fonts to use when engraving? Therefore, more usability and more choice for the engraver and composer? Of course, people are free to do whatever they want with their own time and efforts. But if you do it out of a feeling of contributing to LilyPond, it may be worth looking quite closer before investing a lot of effort. You might also be disappointed in the lack of uptake by the LilyPond websites, manuals and other resources for proprietary font support. But as Urs points out, LaTex and so on do not have this problem. Why restrict lilypond to one font? I might not be dissapointed! :-) Am I the only one that wants more font choices? Maybe! URL:http://www.gnu.org/prep/maintain/maintain.html#Ethical-and-Philosophical-Consideration states: A GNU package should not recommend use of any non-free program, nor should it require a non-free program (such as a non-free compiler or IDE) to build. Fonts are a program under this definition, are they? Aren't they purely a runtime construct? Does Emmentaler have to be compiled in presently? Andrew ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Andrew Bernard andrew.bern...@gmail.com schrieb: Greetings List, On 10/08/13 6:57 PM, Urs Liska wrote: Of course this is all quite complex and difficult. Which is why this discussion thread is important, I reckon. One thought: Of course you can buy commercial fonts and use them with LaTeX. I use commercial fonts with the open source ConTeXT program. But the free TeX distros won't for example packages that are macros supporting non-free fonts. Can you explain that more? Not right now. Go to CTAN-upload. Either on that page or on the referenced texlive contribution page you'll find more details. HTH Urs Although I personally would like to have the option to use proprietary fonts with LilyPond. Not proprietary, but SMuFL fonts, commercially packaged! :-) Emmentaler is, in effect, proprietary, although free. Andrew ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Andrew Bernard andrew.bern...@gmail.com writes: On 10/08/13 7:10 PM, David Kastrup wrote: Of course, people are free to do whatever they want with their own time and efforts. But if you do it out of a feeling of contributing to LilyPond, it may be worth looking quite closer before investing a lot of effort. You might also be disappointed in the lack of uptake by the LilyPond websites, manuals and other resources for proprietary font support. But as Urs points out, LaTex and so on do not have this problem. I recommend you reread what Urs write: TeXlive does not distribute support files for non-free fonts. Now it is not really because it would be a problem, but rather because it does not help the project, and you can't test that kind of stuff anyway without acquiring proprietary software. Why restrict lilypond to one font? I might not be dissapointed! :-) Then I suggest you take your case to those who choose propretary licenses for their fonts. That's not the fault of the LilyPond project. Am I the only one that wants more font choices? Maybe! URL:http://www.gnu.org/prep/maintain/maintain.html#Ethical-and-Philosophical-Consideration states: A GNU package should not recommend use of any non-free program, nor should it require a non-free program (such as a non-free compiler or IDE) to build. Fonts are a program under this definition, are they? If a system will produce the intended output only with the use of proprietary components, then the conditions for which this sentence has been written are met. Whether or not you try your hand at mincing words. We hear from Barack Obama What you're not seeing is people actually abusing these programs. which is indeed a proper reflection of the design begind the secret programs: the point of the secrecy is making you not see the abuse. He is careful not to state What I am not seeing or What isn't happening. Which is more a sign of professional pride (he is a lawyer, after all) than of necessity: a number of officials, starting with the Attorney General who should actually prosecute perjury, have demonstrated that straightforward lying with impunity under oath is fair game in American politics. Sorry for getting distracted, I just wanted to explain why I am currently possibly even less amused by semantic games than otherwise. Aren't they purely a runtime construct? Does Emmentaler have to be compiled in presently? Juggling words does not replace looking at the underlying issues. At the current point of time, namely where a generic drop-in interface _not_ requiring specific adaptation to proprietary fonts is not feasible, it is more important to look at the issues for using actually free fonts like Gonville or the Jazz font project that has come up here a few times. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
On Sat, Aug 10, 2013 at 5:46 AM, David Kastrup d...@gnu.org wrote: Andrew Bernard andrew.bern...@gmail.com writes: On 10/08/13 7:10 PM, David Kastrup wrote: Of course, people are free to do whatever they want with their own time and efforts. But if you do it out of a feeling of contributing to LilyPond, it may be worth looking quite closer before investing a lot of effort. You might also be disappointed in the lack of uptake by the LilyPond websites, manuals and other resources for proprietary font support. But as Urs points out, LaTex and so on do not have this problem. I recommend you reread what Urs write: TeXlive does not distribute support files for non-free fonts. Now it is not really because it would be a problem, but rather because it does not help the project, and you can't test that kind of stuff anyway without acquiring proprietary software. There is the fontspec package, primarily used with XeLaTeX, the purpose of which is to allow one to use any font in a LaTeX document, including proprietary fonts (whether you call the ability to use proprietary fonts intentional or incidental is likely one of those dreaded semantic distinctions). I think we're getting hung up on the fact that SMuFL is being promulgated by a corporate entity and the only implementation of SMuFL is produced by that corporate entity (and that most of the musical font work is being done by other corporate entities releasing them under proprietary licenses). Having a standard and being interoperable with that standard makes it easier for *any* font designer to build fonts for LilyPond and for any software package to use LilyPond fonts, whether the font or program happens to be open source or proprietary. I have a question. Does LilyPond currently have a set of documented standards to tell prospective font designers *explicitly* (1) how to set up their fonts for them to be referenced by LilyPond (glyph names), and (2) the metrics necessary to make their fonts work with LilyPond? One of the barriers I see to a lot of extensibility in this area is that even though LilyPond is open source, it is not exactly clear (and maybe I'm just not looking in the right place) what one is to do to build on to it. I was digging into the notehead file to fix an issue with some of the shaped noteheads and on a couple of the things I was looking at, it was very much a guess and check and hope nothing breaks. I realize that the default answer to my question (if no such documentation exists) is, Well, if it matters that much to you, get your hands dirty and do something about it. And you're probably right, but someone not already familiar with how the fonts work writing documentation to how the fonts work sounds a bit, well, counterintuitive. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Carl Peterson carlopeter...@gmail.com schrieb: On Sat, Aug 10, 2013 at 5:46 AM, David Kastrup d...@gnu.org wrote: Andrew Bernard andrew.bern...@gmail.com writes: On 10/08/13 7:10 PM, David Kastrup wrote: Of course, people are free to do whatever they want with their own time and efforts. But if you do it out of a feeling of contributing to LilyPond, it may be worth looking quite closer before investing a lot of effort. You might also be disappointed in the lack of uptake by the LilyPond websites, manuals and other resources for proprietary font support. But as Urs points out, LaTex and so on do not have this problem. I recommend you reread what Urs write: TeXlive does not distribute support files for non-free fonts. Now it is not really because it would be a problem, but rather because it does not help the project, and you can't test that kind of stuff anyway without acquiring proprietary software. There is the fontspec package, primarily used with XeLaTeX, the purpose of which is to allow one to use any font in a LaTeX document, including proprietary fonts (whether you call the ability to use proprietary fonts intentional or incidental is likely one of those dreaded semantic distinctions). That's about what I feel about it. Having the option to use any font, including commercial ones, was one of the things that finally made me switch to LaTeX. If OpnOffice forced me to use free fonts exclusively I probably wouldn't use it. I think we're getting hung up on the fact that SMuFL is being promulgated by a corporate entity and the only implementation of SMuFL is produced by that corporate entity (and that most of the musical font work is being done by other corporate entities releasing them under proprietary licenses). Having a standard and being interoperable with that standard makes it easier for *any* font designer to build fonts for LilyPond and for any software package to use LilyPond fonts, whether the font or program happens to be open source or proprietary. Exactly. I think this would be an interesting situation. And it would probably outweigh the fact that we'd give competitors the chance using LilyPond's font too. I have a question. Does LilyPond currently have a set of documented standards to tell prospective font designers *explicitly* (1) how to set up their fonts for them to be referenced by LilyPond (glyph names), and (2) the metrics necessary to make their fonts work with LilyPond? One of the barriers I see to a lot of extensibility in this area is that even though LilyPond is open source, it is not exactly clear (and maybe I'm just not looking in the right place) what one is to do to build on to it. I was digging into the notehead file to fix an issue with some of the shaped noteheads and on a couple of the things I was looking at, it was very much a guess and check and hope nothing breaks. I realize that the default answer to my question (if no such documentation exists) is, Well, if it matters that much to you, get your hands dirty and do something about it. And you're probably right, but someone not already familiar with how the fonts work writing documentation to how the fonts work sounds a bit, well, counterintuitive. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Re: SMuFL
As a fairly outside observer who is only an occasional user of Lilypond On 08/09/2013 11:43 PM, Carl Peterson wrote: The concern I have on SMuFL is that it is an as-of-yet immature standard without broad support outside of Steinberg. ... Will it be a futile effort because the SMuFL standard dies from lack of interest/acceptance? A flip side of that question is: How much would adding Lilypond support for SMuFL help to *make* SMuFL into an accepted and common standard? I don't want to say you guys should (not) support SMuFL, but I think that question is worth thinking about, even if you decide the answer is probably not much. :-) Evan ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Evan Driscoll drisc...@cs.wisc.edu writes: As a fairly outside observer who is only an occasional user of Lilypond On 08/09/2013 11:43 PM, Carl Peterson wrote: The concern I have on SMuFL is that it is an as-of-yet immature standard without broad support outside of Steinberg. ... Will it be a futile effort because the SMuFL standard dies from lack of interest/acceptance? A flip side of that question is: How much would adding Lilypond support for SMuFL help to *make* SMuFL into an accepted and common standard? Depends on what you mean with adding LilyPond support. a) LilyPond can read and process SMuFL fonts optionally - nothing b) LilyPond converts its own font infrastructure to SMuFL - some c) Someone takes LilyPond fonts and converts them to SMuFL - some What is in it for LilyPond in the context of free software? a) depends on the availability of free SMuFL fonts. If none - nothing. b) Ongoing and existing free fonts for LilyPond (Gonville, Jazz) stop working - worse than nothing c) Nothing. I don't want to say you guys should (not) support SMuFL, but I think that question is worth thinking about, even if you decide the answer is probably not much. :-) Like with many standards, it will be the task of those who want to promote the standard to do so with sufficient incentives. For a free software project, the incentive would be freely redistributable fonts. If we can't include the fonts in, say, a DFSG-compliant distribution like Debian or bundle them with our GPL-licensed downloads, the benefits for LilyPond as free software don't exist. For letting proprietary vendors get interested in a standard, gratis or cheap might be enough with regard to the incentive material. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Andrew Bernard andrew.bern...@gmail.com writes: Emmentaler is, in effect, proprietary, although free. I disagree. I think so poorly documented that in practice almost no one can understand how it works still can't qualify as in effect proprietary. It just qualifies as needing a huge amount of work; work that there is absolutely no one on earth who BOTH wants to do it and already knows how. I guess that leaves three possibilities for Emmentaler: - Someone who doesn't really want to (but is fully capable of) writing two very specific major pieces of documentation - Successfully Using Emmentaler Outside of Lilypond and Jarlsberg: A Start-to-Finish Guide to Creating New Drop-In Replacements for Emmentaler - decides to spend time writing them anyway. - Or: Someone who wants to write those docs but has no idea how, spends an inordinate amount of time and energy learning it by himself. - Or: Everyone waits to see what will happen. -- David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
I think so poorly documented that in practice almost no one can understand how it works still can't qualify as in effect proprietary. It is not *that* badly documented. However, the number of people who understand Metafont are rather small today. - Someone who doesn't really want to (but is fully capable of) writing two very specific major pieces of documentation - Successfully Using Emmentaler Outside of Lilypond and Jarlsberg: A Start-to-Finish Guide to Creating New Drop-In Replacements for Emmentaler - decides to spend time writing them anyway. Writing better documentation is *always* a good idea. If you look at the applied patches to the lilypond repository, more than 90% are documentation patches. However, there isn't an urgent need to improve things w.r.t. Emmentaler, because it simply works, and apparently no volunteer has enough interest to change this situation. In other words: If there is no itch, noone will scratch. Werner ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Werner LEMBERG w...@gnu.org writes: I think so poorly documented that in practice almost no one can understand how it works still can't qualify as in effect proprietary. It is not *that* badly documented. However, the number of people who understand Metafont are rather small today. git shortlog -sn mf/ 459 Han-Wen Nienhuys 160 Jan Nieuwenhuizen 104 Werner Lemberg 20 Jürgen Reuter 16 Carl D. Sorensen 15 Janek Warchoł 11 Mats Bengtsson 7 Bertrand Bordage 7 Maximilian Albert 4 David Kastrup 4 Graham Percival 4 John Mandereau 4 Phil Holmes 4 Tom Cato Amundsen 3 Erlend Aasland 3 Marc Hohl 3 Patrick McCarty 3 Reinhold Kainhofer 3 Rune Zedeler 2 Aleksandr Andreev 2 Neil Puttock 1 Benkő Pál 1 Carsten Steger 1 Glen Prideaux 1 Julien Rioux 1 Mark Polesky 1 Michael Welsh Duggan 1 Nicolas Sceaux Some of those will have worked on the build system rather than the fonts themselves, but I doubt that all of those working on the fonts had previous exposure to Metafont/Metapost. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Am 09.08.2013 14:39, schrieb Urs Liska: Hi all, although I suspect this could once more become a longish and scattered thread, I feel forced to bring it up here. :) What do you think: would it make sense to open up LilyPond thinking to the idea of SMuFL brought up by Steinberg and Daniel Spreadbury? http://www.smufl.org http://www.smufl.org/ Of course currently it's only their new Bravura font that complies to that proposed standard. But I can imagine there will be more 'participators' in mid-term future. Making Emmentaler/Feta SMuFL-compliant could have several advantages IMHO: - Open up the possibility (or at least make a step in that direction) to use alternative fonts for LilyPond engraved scores. Once LilyPond could use SMuFL compliant fonts it would be easy to use any new font that adheres to the standard - Increasing LilyPond's 'cooperativeness' (a technical aspect as well as a 'social' signal) +1 If we were able to increase lilyponds cooperativeness, it would help lilypond. I don't know, what it would take to make Emmentaler/Feta SMuFL compliant, but I would appreciate such a step. It might help steinberg and Daniel Spreadbury promote this new standard - IMHO this is a good thing - it is an open standard and lilypond might use any SMuFL compliant font. And that we don't forget it ;) musicXML export would also open lilypond for other uses. Jan-Peter Voigt ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Am 09.08.2013 15:11, schrieb Jan-Peter Voigt: Am 09.08.2013 14:39, schrieb Urs Liska: Hi all, although I suspect this could once more become a longish and scattered thread, I feel forced to bring it up here. :) What do you think: would it make sense to open up LilyPond thinking to the idea of SMuFL brought up by Steinberg and Daniel Spreadbury? http://www.smufl.org http://www.smufl.org/ Of course currently it's only their new Bravura font that complies to that proposed standard. But I can imagine there will be more 'participators' in mid-term future. Making Emmentaler/Feta SMuFL-compliant could have several advantages IMHO: - Open up the possibility (or at least make a step in that direction) to use alternative fonts for LilyPond engraved scores. Once LilyPond could use SMuFL compliant fonts it would be easy to use any new font that adheres to the standard - Increasing LilyPond's 'cooperativeness' (a technical aspect as well as a 'social' signal) +1 If we were able to increase lilyponds cooperativeness, it would help lilypond. I don't know, what it would take to make Emmentaler/Feta SMuFL compliant, Of course I don't know that either, but I see a few steps: 1) Modify the mapping of glyphs to Unicode numbers I think that would be very simple, just a matter of remapping them in a suitable application. If LilyPond really accesses the glyphs by their names this wouldn't even imply any internal changes. 2) Adapt anchors and (perhaps) scaling If I understand the SMuFL specification correctly it also specifies where the anchors should be set in the glyphs. I don't know what this would mean in terms of development. Maybe it's 'just' a matter of updating the glyphs and one setting in LilyPond for each glyph. But it could also be that one would have to re-define the glyph positioning in LilyPond at a deeper level, with all kinds of possible side-effects ... but I would appreciate such a step. It might help steinberg and Daniel Spreadbury promote this new standard - IMHO this is a good thing - it is an open standard and lilypond might use any SMuFL compliant font. Yes, and that might justify the work in my step 2) above. I can imagine that the option of using other fonts outweighs that other applications can then use 'our' font. And that we don't forget it ;) musicXML export would also open lilypond for other uses. Well, unfortunately (and completely unexpectedly ...) noone stepped out with unlimited time and this specific motivation in the meantime ;-) Urs Jan-Peter Voigt ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
On Fri, Aug 9, 2013 at 9:21 AM, Urs Liska u...@openlilylib.org wrote: Am 09.08.2013 15:11, schrieb Jan-Peter Voigt: Of course I don't know that either, but I see a few steps: 1) Modify the mapping of glyphs to Unicode numbers I think that would be very simple, just a matter of remapping them in a suitable application. If LilyPond really accesses the glyphs by their names this wouldn't even imply any internal changes. But then, if we intended to allow LilyPond to use other SMuFL-compliant fonts, there *would* be internal changes, as we would have to have, at a minimum, a mapping table to convert glyph names to codepoints. The broader question for me is how many Feta glyphs *aren't* in the SMuFL standard and how many SMuFL/Unicode codepoints aren't already represented in Feta. Since they're looking for feedback, we may be able to contribute to the community by providing such a list of glyphs that may need to be added to the standard. 2) Adapt anchors and (perhaps) scaling If I understand the SMuFL specification correctly it also specifies where the anchors should be set in the glyphs. I don't know what this would mean in terms of development. Maybe it's 'just' a matter of updating the glyphs and one setting in LilyPond for each glyph. But it could also be that one would have to re-define the glyph positioning in LilyPond at a deeper level, with all kinds of possible side-effects ... I read through/skimmed the SMuFL standard. The basic design concept/scale is a 1em high five-line staff. Pretty much anything that is positioned relative to a pitch is drawn so that the line y=0 in the glyph's coordinate system corresponds to the reference pitch. Flags have the attachment point as the origin. Generally all glyphs have x=0 at the leftmost edge. I don't know how that necessarily translates for our purposes, Carl ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Am 09.08.2013 15:58, schrieb Carl Peterson: On Fri, Aug 9, 2013 at 9:21 AM, Urs Liska u...@openlilylib.org mailto:u...@openlilylib.org wrote: Am 09.08.2013 15:11, schrieb Jan-Peter Voigt: Of course I don't know that either, but I see a few steps: 1) Modify the mapping of glyphs to Unicode numbers I think that would be very simple, just a matter of remapping them in a suitable application. If LilyPond really accesses the glyphs by their names this wouldn't even imply any internal changes. But then, if we intended to allow LilyPond to use other SMuFL-compliant fonts, there *would* be internal changes, Yes, of course. What I meant is that, as a very first step, we could probably change the mapping of glyphs to codepoints without needing internal changes. as we would have to have, at a minimum, a mapping table to convert glyph names to codepoints. The broader question for me is how many Feta glyphs *aren't* in the SMuFL standard and how many SMuFL/Unicode codepoints aren't already represented in Feta. Since they're looking for feedback, we may be able to contribute to the community by providing such a list of glyphs that may need to be added to the standard. These are two different issues, I think: Regarding glyphs defined in SMuFL that aren't present in Feta we could simply use them as inspiration what _could_ be added to Feta/LilyPond. The standard doesn't require any specific coverage. Its point is to guarantee that _if_ a font provides e.g. the fermata sign it's guaranteed to be accessible at a specific codepoint. The other way round is exactly as you say: making suggestions for additions to the standard is a good thing (only question: who'd volunteer comparing ...) Maybe we should start with suggesting the CreativeCommons logo to balance the no-copying one ;-) 2) Adapt anchors and (perhaps) scaling If I understand the SMuFL specification correctly it also specifies where the anchors should be set in the glyphs. I don't know what this would mean in terms of development. Maybe it's 'just' a matter of updating the glyphs and one setting in LilyPond for each glyph. But it could also be that one would have to re-define the glyph positioning in LilyPond at a deeper level, with all kinds of possible side-effects ... I read through/skimmed the SMuFL standard. The basic design concept/scale is a 1em high five-line staff. Pretty much anything that is positioned relative to a pitch is drawn so that the line y=0 in the glyph's coordinate system corresponds to the reference pitch. Flags have the attachment point as the origin. Generally all glyphs have x=0 at the leftmost edge. I don't know how that necessarily translates for our purposes, I don't know either. I'm only afraid it couldn't be feasible to 'simply' modify the right parameters but that it could imply complete 'retuning' of the layout system. Urs Carl ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
SMuFL has nothing much to do with preserving the Unicode standard. If you can get the Unicode consortium to participate in outlining SMuFL stuffs in its standard than it would be good, but an abstracted standard used by one or two applications is a bad idea especially for one text based like ours. It reduces the odds of universal support that the Unicode consortium is trying to create. We don't need such an extra layer of confusion. We just need to apply pressure to the consortium to get the things that are missing encoded. That is my stance. Shane On Fri, Aug 9, 2013 at 10:24 AM, Urs Liska u...@openlilylib.org wrote: Am 09.08.2013 15:58, schrieb Carl Peterson: On Fri, Aug 9, 2013 at 9:21 AM, Urs Liska u...@openlilylib.org wrote: Am 09.08.2013 15:11, schrieb Jan-Peter Voigt: Of course I don't know that either, but I see a few steps: 1) Modify the mapping of glyphs to Unicode numbers I think that would be very simple, just a matter of remapping them in a suitable application. If LilyPond really accesses the glyphs by their names this wouldn't even imply any internal changes. But then, if we intended to allow LilyPond to use other SMuFL-compliant fonts, there *would* be internal changes, Yes, of course. What I meant is that, as a very first step, we could probably change the mapping of glyphs to codepoints without needing internal changes. as we would have to have, at a minimum, a mapping table to convert glyph names to codepoints. The broader question for me is how many Feta glyphs *aren't* in the SMuFL standard and how many SMuFL/Unicode codepoints aren't already represented in Feta. Since they're looking for feedback, we may be able to contribute to the community by providing such a list of glyphs that may need to be added to the standard. These are two different issues, I think: Regarding glyphs defined in SMuFL that aren't present in Feta we could simply use them as inspiration what _could_ be added to Feta/LilyPond. The standard doesn't require any specific coverage. Its point is to guarantee that _if_ a font provides e.g. the fermata sign it's guaranteed to be accessible at a specific codepoint. The other way round is exactly as you say: making suggestions for additions to the standard is a good thing (only question: who'd volunteer comparing ...) Maybe we should start with suggesting the CreativeCommons logo to balance the no-copying one ;-) 2) Adapt anchors and (perhaps) scaling If I understand the SMuFL specification correctly it also specifies where the anchors should be set in the glyphs. I don't know what this would mean in terms of development. Maybe it's 'just' a matter of updating the glyphs and one setting in LilyPond for each glyph. But it could also be that one would have to re-define the glyph positioning in LilyPond at a deeper level, with all kinds of possible side-effects ... I read through/skimmed the SMuFL standard. The basic design concept/scale is a 1em high five-line staff. Pretty much anything that is positioned relative to a pitch is drawn so that the line y=0 in the glyph's coordinate system corresponds to the reference pitch. Flags have the attachment point as the origin. Generally all glyphs have x=0 at the leftmost edge. I don't know how that necessarily translates for our purposes, I don't know either. I'm only afraid it couldn't be feasible to 'simply' modify the right parameters but that it could imply complete 'retuning' of the layout system. Urs Carl ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Greetings List, There's an old IT joke that the beauty of having standards is that there are so many to choose from! I agree with Shane. The SMuFL standard is just a specification cooked up by Steinberg for the new program. It's been possible for them to consider this since they are architecting the program from scratch. But it's a step away and outside of the hugely important work the Unicode Consortium have been doing for decades. No matter how clever SMuFL is, it's not well conceived philosophically for this reason. Lilyponders would be better off devoting time to working with the Unicode Consortium. Then a music glyph standard would truly have universal acceptance, due to the international respect Unicode has. Unicode already has a Symbols area and the 6.2 standard provides a lot of glyphs. As a person involved with 18c harpsichord music myself, I note that they provide the glyphs to do pretty much all the 18c ornaments, which can be built up from parts. So the Unicode Consortium is certainly serious about music aspects. Andrew On 10/08/13 1:47 AM, Shane Brandes wrote: SMuFL has nothing much to do with preserving the Unicode standard. If you can get the Unicode consortium to participate in outlining SMuFL stuffs in its standard than it would be good, but an abstracted standard used by one or two applications is a bad idea especially for one text based like ours. It reduces the odds of universal support that the Unicode consortium is trying to create. We don't need such an extra layer of confusion. We just need to apply pressure to the consortium to get the things that are missing encoded. That is my stance. Shane ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
The SMuFL standard is just a specification cooked up by Steinberg for the new program. It's been possible for them to consider this since they are architecting the program from scratch. But it's a step away and outside of the hugely important work the Unicode Consortium have been doing for decades. I disagree, and I think that you are completely missing the purpose of SMuFL: It collects *glyphs* which are used somewhere, and which people need somehow. Compare this to the Adobe Glyph Collections like `Adobe-Korea1-2' or `Adobe-GB1-5'. As they write on smufl.org: The goal of SMuFL is to establish a new standard glyph mapping for musical symbols that is optimised for OpenType fonts and that can be adopted by a variety of software vendors and font designers, for the benefit of all users of music notation software. Unicode is a *character* standard, mainly to *exchange* information. It is *not* related to glyphs, or to fonts. The SMuFL team correctly maps the glyphs to the Private Area of Unicode, and they don't suggest the inclusion of any of those entities into the Unicode standard. Whether SmuFL is centered on Steinberg's new program is basically completely irrelevant. I'm quite sure that they are willing to add glyphs which Lilypond needs and which aren't covered yet. Not that this is really necessary, as far as I can see... Werner ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
On Sat, Aug 10, 2013 at 12:21 AM, Werner LEMBERG w...@gnu.org wrote: The SMuFL standard is just a specification cooked up by Steinberg for the new program. It's been possible for them to consider this since they are architecting the program from scratch. But it's a step away and outside of the hugely important work the Unicode Consortium have been doing for decades. I disagree, and I think that you are completely missing the purpose of SMuFL: It collects *glyphs* which are used somewhere, and which people need somehow. Compare this to the Adobe Glyph Collections like `Adobe-Korea1-2' or `Adobe-GB1-5'. As they write on smufl.org: The goal of SMuFL is to establish a new standard glyph mapping for musical symbols that is optimised for OpenType fonts and that can be adopted by a variety of software vendors and font designers, for the benefit of all users of music notation software. Unicode is a *character* standard, mainly to *exchange* information. It is *not* related to glyphs, or to fonts. The SMuFL team correctly maps the glyphs to the Private Area of Unicode, and they don't suggest the inclusion of any of those entities into the Unicode standard. Whether SmuFL is centered on Steinberg's new program is basically completely irrelevant. I'm quite sure that they are willing to add glyphs which Lilypond needs and which aren't covered yet. Not that this is really necessary, as far as I can see... Werner The distinction I'm seeing is that the Unicode Standard and SMuFL are two layers of standardization. What I see is that Unicode tells us what the glyphs mean, (so that we use the same code point in the font to refer to the same thing). SMuFL, on the other hand, tells us how to draw and scale those glyphs so that they can be handled the same way regardless of the actual font. The concern I have on SMuFL is that it is an as-of-yet immature standard without broad support outside of Steinberg. If we start working on SMuFL specifically, will the SMuFL standard look the same when we get done as it does now? Will it be a futile effort because the SMuFL standard dies from lack of interest/acceptance? Carl ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SMuFL
Unicode is a *character* standard, mainly to *exchange* information. It is *not* related to glyphs, or to fonts. The SMuFL team correctly maps the glyphs to the Private Area of Unicode, and they don't suggest the inclusion of any of those entities into the Unicode standard. The distinction I'm seeing is that the Unicode Standard and SMuFL are two layers of standardization. What I see is that Unicode tells us what the glyphs mean, (so that we use the same code point in the font to refer to the same thing). SMuFL, on the other hand, tells us how to draw and scale those glyphs so that they can be handled the same way regardless of the actual font. Well, yes. It's hard to change to a different font if such basic assumptions aren't met. The concern I have on SMuFL is that it is an as-of-yet immature standard without broad support outside of Steinberg. If we start working on SMuFL specifically, will the SMuFL standard look the same when we get done as it does now? Will it be a futile effort because the SMuFL standard dies from lack of interest/acceptance? Unicode essentially had the same problem in the very beginning. After a few years, it was clear that it was superior to everything else, and many more companies and organizations started to support it. SMuFL will evolve, certainly. It's tagged as 0.x, so we have to *expect* that it will change. Supporting SMuFL right now is futile, of course, but the main question is whether we are going to make Lilypond support SMuFL in general, for example, by providing a script and/or data tables to convert an SMuFL font into a Lilypond font. And in case some glyphs are missing, we should now ask them to include such glyphs. Werner ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
