Re: Context.Grob considered as symbol list
Werner LEMBERG wl at gnu.org writes: Instead of having an optional argument Remember that David's previous approach used no optional arguments, the optional components were attached with dots to the core arguments \override [Context.]Grob property[.subproperty] = #value \tweak [Grob.]property.[subproperty] value c2 I would prefer that both commands simply accept such a hierarchy, making e.g. \override color ... \override Accidental.color ... \override Voice.Accidental.color ... and \tweak color ... \tweak Accidental.color ... \tweak Voice.Accidental.color ... valid syntax Remember that by far the most common cases use no optional components, thus no dots in the old syntax. Also remember that \override color = #blue will not do anything useful even if it is valid syntax. (David's latest patch prints a reasonable message for the error above, before crashing.) I would prefer to keep David's previous syntax in documentation, even if we accept the fully-dotted form, because the space helps me find my way when copying new forms from the manuals. \override Ceol.Clochan dath.mion = #glas I forget a lot, but am reminded seeing the above that \override always takes a grob (sometimes with context to its left) and the property (rarely with sub-properties to its right). ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
Keith OHara k-ohara5...@oco.net writes: Werner LEMBERG wl at gnu.org writes: Instead of having an optional argument Remember that David's previous approach used no optional arguments, the optional components were attached with dots to the core arguments \override [Context.]Grob property[.subproperty] = #value \tweak [Grob.]property.[subproperty] value c2 I would prefer that both commands simply accept such a hierarchy, making e.g. \override color ... \override Accidental.color ... \override Voice.Accidental.color ... and \tweak color ... \tweak Accidental.color ... \tweak Voice.Accidental.color ... valid syntax Remember that by far the most common cases use no optional components, thus no dots in the old syntax. Also remember that \override color = #blue will not do anything useful even if it is valid syntax. (David's latest patch prints a reasonable message for the error above, before crashing.) Aborting with an error message? I am actually not all too sure. At some point of time I ran out of steam accommodating the never satisfied. I would prefer to keep David's previous syntax in documentation, even if we accept the fully-dotted form, because the space helps me find my way when copying new forms from the manuals. \override Ceol.Clochan dath.mion = #glas I forget a lot, but am reminded seeing the above that \override always takes a grob (sometimes with context to its left) and the property (rarely with sub-properties to its right). I suggest that you then take responsibility for your side in the shouting match. It would certainly simplify both code and concept (as witnessed by me taking almost a week, admittedly while other work of mine was being shouted down in parallel, just for coming up with a still faulty implementation), but that has never been a strong reason here. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond Feta font license
On Wed, Oct 17, 2012 at 8:37 PM, David Kastrup d...@gnu.org wrote: I just want to let you know that I got a request from two guys that state that they are developing a drum sheet music editor. They ask me if I can give my approval to you for switching the Feta font license from GNU to GNU+OFL, such that their code need not be open source. They also refer to a discussion in the context of the Waltrop meeting. Ugh. As far as I understood the discussion, the idea was to help other free software projects not under the GPL, not to support non-free software. I don't have any copyright in Feta fonts myself i think, but if the sole currently known reason for relicensing was to help non-free software, I'd recommend against it. It would be against the spirit of the GNU project I believe. The idea behind this is twofold: first, the GPL does not make sense for a font. Second, the font can be used independently of LilyPond, and thus it is in a sense a standalone work, the use of which does not create a derivative work. Although, this project in particular is not GPLd, questions about using Feta have popped up from time to time before from others, and the OFL is a way to answer all these questions in one fell swoop. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond Feta font license
On 10/18/2012 09:38 AM, Han-Wen Nienhuys wrote: The idea behind this is twofold: first, the GPL does not make sense for a font. That's not entirely true. Obviously it's not a good condition for use of a font in a document, and you _can't_ copyright the _appearance_ of the font, but it makes sense for GPL to be applied to the underlying code of a font so long as you have an exception in place that permits embedding in a document -- see: https://www.gnu.org/licenses/gpl-faq.html#FontException https://www.fsf.org/blogs/licensing/20050425novalis Second, the font can be used independently of LilyPond, and thus it is in a sense a standalone work, the use of which does not create a derivative work. Yea, this seems a broadly correct assertion with respect to fonts although the precise interpretation might differ depending on whether (and how) you bundle the font together with other software. On a related note, this raises the issue of how Lilypond itself bundles the fonts -- as an internal part of Lilypond, or to install as a system font? See: https://bugs.launchpad.net/ubuntu/+source/lilypond/+bug/174369 AFAICS this latter issue is why e.g. if you open up a Lilypond-generated SVG, PS, etc. in Inkscape, all the Feta font characters display as gobbledegook. Although, this project in particular is not GPLd, questions about using Feta have popped up from time to time before from others, and the OFL is a way to answer all these questions in one fell swoop. Even with just GPL+exception (the embedding exception is important; is it in place for Feta?), it's most likely possible for a non-GPL, even proprietary, application to use the Feta font, and even distribute it as part of a collection of software, so long as the font is included as a standalone element and not integrated into the code in other ways. It may be worth touching base with FSF and related bodies on this. But (GPL+exception)+OPF is a fairly standard way to licence a font and does remove uncertainties on the part of other software developers. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Context.Grob considered as symbol list
Keith OHara k-ohara5...@oco.net writes:
Werner LEMBERG wl at gnu.org writes:
Instead of having an optional argument
Remember that David's previous approach used no optional arguments,
the optional components were attached with dots to the core arguments
\override [Context.]Grob property[.subproperty] = #value
\tweak [Grob.]property.[subproperty] value c2
I would prefer that both commands simply accept such
a hierarchy, making e.g.
\override color ...
\override Accidental.color ...
\override Voice.Accidental.color ...
and
\tweak color ...
\tweak Accidental.color ...
\tweak Voice.Accidental.color ...
valid syntax
That's what is accepted in the current version of the patch. Of course,
except for \tweak Voice.Accidental.color which makes _absolutely_ no
sense whatsoever since tweaks are not associated with contexts. And
actually, it _will_ get accepted but will probably complain later that
the tweaked grob does not have a grob property called Voice.
Remember that by far the most common cases use no optional components,
thus no dots in the old syntax. Also remember that
\override color = #blue
will not do anything useful even if it is valid syntax. (David's latest
patch prints a reasonable message for the error above, before
crashing.)
It just does the following non-fatal error in the current version
(updated at origin/dev/syntax):
xxx.ly:1:12: error: bad grob property path
{ \override
color = #blue }
That's good enough.
I would prefer to keep David's previous syntax in documentation, even if
we accept the fully-dotted form, because the space helps me find my way
when copying new forms from the manuals.
\override Ceol.Clochan dath.mion = #glas
I forget a lot, but am reminded seeing the above that \override always
takes a grob (sometimes with context to its left) and the property
(rarely with sub-properties to its right).
On the other hand, things like \overrideProperty can only have one
interface or the other, and put a single dotted symbol list here to
specify the path with no alternative readings is dead simple and
straightforward. And starting with version 2.19, or at the latest 2.21,
I would want to remove the compatibility mode which is really
complicating things both in the parser as well as conceptually.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Broken time signature glyphs?
John Mandereau john.mander...@gmail.com writes: Il giorno mar, 18/09/2012 alle 14.11 +0200, David Kastrup ha scritto: John Mandereau john.mander...@gmail.com writes: David, could we bump Fontforge minimum version to 20110222 for the next 2.16 release as well? How would that have to be done? By cherry-picking 236559061d0c32fcbe39492dcb444e41f2804145 Author: Janek WarchoĊ janek.lilyp...@gmail.com Date: Mon Aug 27 11:00:24 2012 +0200 Bump Fontforge version requirement (issue 1637) ? Will appear in 2.16.1. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Implement session-terminate in lily.scm (issue 6742043)
LGTM. http://codereview.appspot.com/6742043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Countdown to 20121021
For 23:00 MDT (SInging in a concert that night!) Sunday October 21 Enhancement: Issue 2904 http://code.google.com/p/lilypond/issues/detail?id=2904q=label%3Apatch%20patch%3Dreviewsort=patchcolspec=ID%20Type%20Status%20Priority%20Stars%20Owner%20Patch%20Summary: Patch: Update contributors - R 6689045 http://codereview.appspot.com/6689045/ (has several LGTM, perhaps push without waiting?) Issue 2906 http://code.google.com/p/lilypond/issues/detail?id=2906q=label%3Apatch%20patch%3Dreviewsort=patchcolspec=ID%20Type%20Status%20Priority%20Stars%20Owner%20Patch%20Summary: Patch: New bar line interface: take whichBar into account - R 6695046 http://codereview.appspot.com/6695046/ Cheers, Colin -- I've learned that you shouldn't go through life with a catcher's mitt on both hands. You need to be able to throw something back. -Maya Angelou, poet (1928- ) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
