Re: Context.Grob considered as symbol list

2012-10-18 Thread Werner LEMBERG 

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

Using the dotted form only in the future is fine for me.


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

PATCH: Countdown to 20121021

2012-10-18 Thread Colin Campbell 

For 23:00 MDT (SInging in a concert that night!) Sunday October 21

Enhancement:
Issue 2904 
: 
Patch: Update contributors - R 6689045 
 (has several LGTM, perhaps push 
without waiting?)


 Issue 2906 
: 
Patch: New bar line interface: take whichBar into account - R 
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

Implement session-terminate in lily.scm (issue 6742043)

2012-10-18 Thread lemzwerg 

LGTM.

http://codereview.appspot.com/6742043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Broken time signature glyphs?

2012-10-18 Thread David Kastrup 
John Mandereau  writes:

> Il giorno mar, 18/09/2012 alle 14.11 +0200, David Kastrup ha scritto:
>> John Mandereau  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Ċ‚ 
> 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

Re: Context.Grob considered as symbol list

2012-10-18 Thread David Kastrup 
Keith OHara  writes:

> Werner LEMBERG  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: Lilypond Feta font license

2012-10-18 Thread Joseph Rushton Wakeling 

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: Lilypond Feta font license

2012-10-18 Thread Han-Wen Nienhuys 
On Wed, Oct 17, 2012 at 8:37 PM, David Kastrup  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: Context.Grob considered as symbol list

2012-10-18 Thread David Kastrup 
Keith OHara  writes:

> Werner LEMBERG  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