Re: See the new music fonts in action

[David Kastrup]

Abraham Lee  writes:

> On Fri, Aug 1, 2014 at 3:51 PM, Alexander Kobel  wrote:
>>
>> factor is relevant if you set the global staff size to something
>> different than 20, the default.  The usual rule-of-tree used to be
>> something like
>>   myStaffSize = #17.82
>>   #(set-global-staff-size myStaffSize)
>>   #(define fonts (make-pango-font-tree ... (/ myStaffSize 20)))
>>
>> BTW, I never really understood whether it is technically possible to
>> automatically figure out "factor" at the point where
>> make-pango-font-tree is called?  If not, why?  And if yes, is there
>> any reason why it is not done?
>>
>>
>> Best,
>> Alexander
>>
> Ah, yes. I knew there was a reason for the syntax "(/ staff-height pt
> 20)" or its equivalent. I just tried to play around with
> make-pango-font-tree and I couldn't seem to figure out how to
> reference the "staff-height" variable within this function. 
>
> David Kastrup? Anyone? Any ideas?

Well, looking at the definition of set-global-staff-size would seem to
indicate how the size is being set.  I suspect that calculating the
"relevant module" in that manner and then looking up output-scale in it
might do the trick.  But I haven't really understood the output scale
business anyway.  It's not clear to me how it works in every
circumstance.

-- 
David Kastrup

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

Re: thoughts on changing \magnifyMusic, please comment

[Mark Polesky]

Janek Warchoł wrote:
> So, we can say that \magnifyStaff sets staff "size" to an
> absolute value - defined as the fraction of the default
> size - and not "relative" to the previous size.

Not exactly.  A magnifyStaff value is only relative to the
previous staff size the first time it's used in a given
staff.  The value of "1" refers to the settings that are in
effect when magnifyStaff is first called.  After that, then
yes, I suppose it's "absolute".  But it's not precise to say
that it scales the "default" values, since it scales the
user's settings.

>> Subsequent calls to \magnifyStaff will first revert the
>> most recent layer of temporary overrides, but only if
>> the magnification value is different from last time.
>
> - do i understand correctly that this means that
> \magnifyStaff is aware of the previous magnification value
> used?

Yes.  I've added a new Staff context property
`magnifyStaffValue' to store that.

> If so, would it be possible to make a "relative" version
> of \magnifyStaff, similarly to how we have relative and
> absolute markup commands (\large and \larger)?  I think
> this could be useful.

Hmm, sometimes I wonder if we're not wandering into levels
of esoterica here.  At a minimum, we should provide the user
an easy way to do these two things:
  1) ossia staves
  2) small staves for non-piano instruments
 in chamber music scores with piano

This is now available; just throw magnifyStaff in a \with
block and you're done.  Then, to my great surprise, someone
requested the ability to change staff size mid-stream in a
Staff context:
  http://lists.gnu.org/archive/html/lilypond-user/2014-06/msg00400.html

So I made sure that magnifyStaff could do that:
  ...
  \magnifyStaff 0.75
  ...
  \magnifyStaff 1% revert back to initial size
  ...

Now with requests for absolute and relative versions, as
well as this:
  \temporary \magnifyStaff 1.3
  ...
  \undo \magnifyStaff 1.3

...I'm starting to wonder how much of this is really
necessary.  Can anyone provide an actual use case to justify
accommodating either of these requests?

Also, to be honest, I don't really like the idea of the
\larger command, since it feels so arbitrary.  I could do:
   \largerStaff
   \smallerStaff

but I'm not wild about that idea.  I suppose I could also
figure out a way to do:
   \magnifyStaffAbsolute
   \magnifyStaffRelative

but that still seems silly to me.  One thought I had was
putting the burden of reverting on the user, when wanting to
change from one non-default size to another, something like
this:
   ...% size 1
   \magnifyStaff 0.75 % size 0.75
   ...
   \resetStaffSize% size 1
   \magnifyStaff 2% size 2
   ...

Then if one really wanted a "relative" magnifyStaff, they
could do:
   ...% size 1
   \magnifyStaff 0.75 % size 0.75
   ...
   \magnifyStaff 2% size 1.5
   ...

But do you really think this is what users are going to
want?  To me the extra reset command seems needlessly
cumbersome, and the "relative" magnification seems so
non-intuitive, I find it hard to believe that anyone needs a
relative function here, so I just built the reset into the
function itself.  And besides, isn't this already so
esoteric (multiple mid-stream staff size changes?), what
tiny minority are we catering to by even worrying about it?

Sorry if I'm ranting; my questions are sincere, and I'm
happy to take further discussion on the matter.  I think I'm
leaning towards:
  1) keeping magnifyStaff as it is
  2) making magnifyMusic syntax like magnifyStaff
  3) changing magnifyMusic to magnifyVoice

> In general, your work on setting notation size looks
> very nice.  I've been missing such functionality for a
> long time :)

Well, validation is always nice.  :)

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

Re: Simplify the NullVoice context (issue 117050043 by k-ohara5...@oco.net)

[janek . lilypond]

Patchset 4 LGTM :)

I agree that it would be nice to separate melisma stuff from ties, but -
as i've already written on the tracker - that's a topic for another
patch.

https://codereview.appspot.com/117050043/

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

Re: thoughts on changing \magnifyMusic, please comment

[Janek Warchoł]

2014-08-02 9:05 GMT+02:00 Mark Polesky :
> Janek Warchoł wrote:
>> So, we can say that \magnifyStaff sets staff "size" to an
>> absolute value - defined as the fraction of the default
>> size - and not "relative" to the previous size.
>
> Not exactly.  A magnifyStaff value is only relative to the
> previous staff size the first time it's used in a given
> staff.  The value of "1" refers to the settings that are in
> effect when magnifyStaff is first called.  After that, then
> yes, I suppose it's "absolute".  But it's not precise to say
> that it scales the "default" values, since it scales the
> user's settings.

Ok, i see.

>>> Subsequent calls to \magnifyStaff will first revert the
>>> most recent layer of temporary overrides, but only if
>>> the magnification value is different from last time.
>>
>> - do i understand correctly that this means that
>> \magnifyStaff is aware of the previous magnification value
>> used?
>
> Yes.  I've added a new Staff context property
> `magnifyStaffValue' to store that.

What about naming it 'staffSize'?

>> If so, would it be possible to make a "relative" version
>> of \magnifyStaff, similarly to how we have relative and
>> absolute markup commands (\large and \larger)?  I think
>> this could be useful.
>
> Hmm, sometimes I wonder if we're not wandering into levels
> of esoterica here.  At a minimum, we should provide the user
> an easy way to do these two things:
>   1) ossia staves
>   2) small staves for non-piano instruments
>  in chamber music scores with piano
>
> This is now available; just throw magnifyStaff in a \with
> block and you're done.

Yes, that's indeed the basic use-case and it's handled nicely.

> Then, to my great surprise, someone
> requested the ability to change staff size mid-stream in a
> Staff context:
>   http://lists.gnu.org/archive/html/lilypond-user/2014-06/msg00400.html
>
> So I made sure that magnifyStaff could do that:
>   ...
>   \magnifyStaff 0.75
>   ...
>   \magnifyStaff 1% revert back to initial size
>   ...
>
> Now with requests for absolute and relative versions, as
> well as this:
>
>   \temporary \magnifyStaff 1.3
>   ...
>   \undo \magnifyStaff 1.3
>
> ...I'm starting to wonder how much of this is really
> necessary.  Can anyone provide an actual use case to justify
> accommodating either of these requests?

I admit that i don't have an actual use case.  I expect that crazy
composers like Mike (hello Mike! :)) could want to make the staff
progressively bigger and bigger each measure, for example as a fancy
way of indicating global crescendo sustained over many measures.  But
that's just a speculation.

> Also, to be honest, I don't really like the idea of the
> \larger command, since it feels so arbitrary.  I could do:
>\largerStaff
>\smallerStaff
>
> but I'm not wild about that idea.  I suppose I could also
> figure out a way to do:
>\magnifyStaffAbsolute
>\magnifyStaffRelative
>
> but that still seems silly to me.

I don't think we have to provide mechanisms for both relative and
absolute staff scaling right now.  I just think that it's good to
design the functionality (and name the functions) with such
possibility in mind.

> One thought I had was
> putting the burden of reverting on the user, when wanting to
> change from one non-default size to another, something like
> this:
>...% size 1
>\magnifyStaff 0.75 % size 0.75
>...
>\resetStaffSize% size 1
>\magnifyStaff 2% size 2
>...
>
> Then if one really wanted a "relative" magnifyStaff, they
> could do:
>...% size 1
>\magnifyStaff 0.75 % size 0.75
>...
>\magnifyStaff 2% size 1.5
>...
>
> But do you really think this is what users are going to
> want?

I agree that this wouldn't be most intuitive.  I think that the way
\magnifyStaff works now is very good.  Changing staff size relatively
would have to be another function, if we ever decide to support it.

> I think I'm
> leaning towards:
>   1) keeping magnifyStaff as it is
>   2) making magnifyMusic syntax like magnifyStaff
>   3) changing magnifyMusic to magnifyVoice

+1

best,
Janek

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

Re: thoughts on changing \magnifyMusic, please comment

[David Kastrup]

Mark Polesky  writes:

> Janek Warchoł wrote:
>> So, we can say that \magnifyStaff sets staff "size" to an
>> absolute value - defined as the fraction of the default
>> size - and not "relative" to the previous size.
>
> Not exactly.  A magnifyStaff value is only relative to the
> previous staff size the first time it's used in a given
> staff.  The value of "1" refers to the settings that are in
> effect when magnifyStaff is first called.  After that, then
> yes, I suppose it's "absolute".  But it's not precise to say
> that it scales the "default" values, since it scales the
> user's settings.

Sigh.  That's not as much a user interface as it is a nightmare.  It's
sort of hand-waving.

> But do you really think this is what users are going to
> want?  To me the extra reset command seems needlessly
> cumbersome, and the "relative" magnification seems so
> non-intuitive, I find it hard to believe that anyone needs a
> relative function here, so I just built the reset into the
> function itself.  And besides, isn't this already so
> esoteric (multiple mid-stream staff size changes?), what
> tiny minority are we catering to by even worrying about it?
>
> Sorry if I'm ranting; my questions are sincere, and I'm
> happy to take further discussion on the matter.  I think I'm
> leaning towards:
>   1) keeping magnifyStaff as it is
>   2) making magnifyMusic syntax like magnifyStaff
>   3) changing magnifyMusic to magnifyVoice

The takeout may be that several commands doing a clear-defined job may
be warranted.

Personally, I am most uncomfortable with the "be relative to current
settings once" idea: that seems like a total nightmare in situations
using quotes or similar.  The question is where we could access a
reasonably "default" setting that relative references could be based on.

-- 
David Kastrup

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

Re: Rename calc-property-by-copy to copy-property-from-event (issue 122750044 by janek.lilyp...@gmail.com)

[janek . lilypond]

On 2014/08/01 19:31:40, dak wrote:

On 2014/08/01 19:30:45, dak wrote:
> It's a public function, so a convert-rule seems prudent to do.

Purely

internal
> functions are not exported.



Actually, it's probably easier to do an alias rather than a convert

rule.

Like this?  Or is there some special way of creating aliases?

Btw, is the new name optimal?  What about
- grob::event-property
- grob::copy-event-property
- grob::copy-from-event-property
- grob::copy-from-cause
?

https://codereview.appspot.com/122750044/

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

Re: See the new music fonts in action

[Alexander Kobel]

On 08/02/2014 09:00 AM, David Kastrup wrote:

Abraham Lee  writes:


On Fri, Aug 1, 2014 at 3:51 PM, Alexander Kobel  wrote:


BTW, I never really understood whether it is technically possible to
automatically figure out "factor" at the point where
make-pango-font-tree is called?  If not, why?  And if yes, is there
any reason why it is not done?


Ah, yes. I knew there was a reason for the syntax "(/ staff-height pt
20)" or its equivalent. I just tried to play around with
make-pango-font-tree and I couldn't seem to figure out how to
reference the "staff-height" variable within this function.

David Kastrup? Anyone? Any ideas?


Well, looking at the definition of set-global-staff-size would seem to
indicate how the size is being set.  I suspect that calculating the
"relevant module" in that manner and then looking up output-scale in it
might do the trick.  But I haven't really understood the output scale
business anyway.  It's not clear to me how it works in every
circumstance.


That's not quite what I wanted to hear...  If /you/ say that, it makes 
me wonder whether a) the entire business is seriously broken by design 
or b) it's waaay above what I'll ever understand.
I agree that looking up the "relevant module" seems to be the missing 
link.  Anyway, I'll have a look after Aug, 10.



Best,
Alexander

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

PATCHES: Countdown for August 5th 2014

[James]

Hello,

Here is the current patch countdown list. The next countdown will be on
August 5th.

You can always view the most current countdown list here:
http://code.google.com/p/lilypond/issues/list?q=Patch%3Apush%2Ccountdown%2Creview%2Cnew%2Cwaiting&colspec=Patch%20Owner%20ID%20Summary&sort=patch




PUSH:

David Kastrup: Patch: Some refactoring and cleanup in lily/paper-book.cc
http://code.google.com/p/lilypond/issues/detail?id=4035

David Kastrup: All subsequent clef transpositions are marked as optional
http://code.google.com/p/lilypond/issues/detail?id=4033

David Kastrup: Patch: unsmob_pitch -> Pitch::unsmob and related
http://code.google.com/p/lilypond/issues/detail?id=4032

Colin Campbell: Patch: DOC: minor revisions to Easier Editing
http://code.google.com/p/lilypond/issues/detail?id=4031

Keith OHara: deprecate make-simple-closure
http://code.google.com/p/lilypond/issues/detail?id=3993




COUNTDOWN:

: Patch: Support for controlling MIDI expression
http://code.google.com/p/lilypond/issues/detail?id=4042

Mark Polesky: Improvements to magnifyMusic and magnifyStaff.
http://code.google.com/p/lilypond/issues/detail?id=4039

Mark Polesky: Add text-interface to InstrumentName.
http://code.google.com/p/lilypond/issues/detail?id=4038

Mark Polesky: Fix some broken commit references.
http://code.google.com/p/lilypond/issues/detail?id=4034

Mark Polesky: Clarify break-align symbols and space-alist args in IR.
http://code.google.com/p/lilypond/issues/detail?id=4024




REVIEW:

Janek Warchoł: Patch: Rename calc-property-by-copy to
copy-property-from-event
http://code.google.com/p/lilypond/issues/detail?id=4045

David Kastrup: Patch: Revert "Issue 3978: Merge alignment cleanup"
http://code.google.com/p/lilypond/issues/detail?id=4036

Keith OHara: weird attachment of Lyrics to NullVoice in polyphony
http://code.google.com/p/lilypond/issues/detail?id=3825




NEW:

Julien Rioux: lilypond-book includes are not being found when using
lily-output-dir or output options
http://code.google.com/p/lilypond/issues/detail?id=4046

Janek Warchoł: Patch: Allow specifying different alignment for grob and
its parent
http://code.google.com/p/lilypond/issues/detail?id=4022




WAITING:

Urs Liska: Patch: Issue 3916: Add \alternatingTimeSignatures
http://code.google.com/p/lilypond/issues/detail?id=3918

Janek Warchoł: Positioning of "8" under clef symbol in G_8 clef
http://code.google.com/p/lilypond/issues/detail?id=3186

Mike Solomon: Patch: Prevents vertical axis groups with empty skylines
http://code.google.com/p/lilypond/issues/detail?id=3156

Mike Solomon: Patch: Removes the translate_axis call from
axis-group-interface outside-staff positioning.
http://code.google.com/p/lilypond/issues/detail?id=3134

David Kastrup: Patch: Implement music functions in Scheme rather than C++
http://code.google.com/p/lilypond/issues/detail?id=2716




Thank you,
James

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

Re: See the new music fonts in action

[Abraham Lee]

On Sat, Aug 2, 2014 at 4:46 AM, Alexander Kobel  wrote:

On 08/02/2014 09:00 AM, David Kastrup wrote:
Well, looking at the definition of set-global-staff-size would seem 
to

indicate how the size is being set.  I suspect that calculating the
"relevant module" in that manner and then looking up output-scale in 
it

might do the trick.  But I haven't really understood the output scale
business anyway.  It's not clear to me how it works in every
circumstance.

That's not quite what I wanted to hear...  If /you/ say that, it 
makes me wonder whether a) the entire business is seriously broken by 
design or b) it's waaay above what I'll ever understand.
I agree that looking up the "relevant module" seems to be the missing 
link.  Anyway, I'll have a look after Aug, 10.



Best,
Alexander


Well, my question is this. If I can do something like:

#(set-global-staff-size 18)

\paper {
 #(define fonts (make-pango-font-tree ... (/ staff-height pt 20)))
}

where staff-height gets referenced _outside_ of the 
set-global-staff-size call, then why can't we just reference it 
directly within the make-pango-font-tree syntax? It appears that the 
variable/property is stored somewhere, but where? and why can I 
reference it, but make-pango-font-tree can't?


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

Re: default text-font-size

[Janek Warchoł]

Hi Alexander,

2014-08-01 12:15 GMT+02:00 Alexander Kobel :
> Hi all,
>
> can anyone explain me why both numbers 11 and 12 (as in 11pt and 12pt)
> appear in the implementation of add-pango-fonts (scm/font.scm, lines 208,
> 219 and 224)?

I have no idea; this looks really strange.  The difference was
introduced by Han-Wen in c562fc36803e350f856a11366b30708bb69ef407, but
there is no explanation why he made this change.

best,
Janek

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

Re: See the new music fonts in action

[David Kastrup]

Abraham Lee  writes:

> On Sat, Aug 2, 2014 at 4:46 AM, Alexander Kobel  wrote:
>> On 08/02/2014 09:00 AM, David Kastrup wrote:
>>> Well, looking at the definition of set-global-staff-size would seem
>>> to
>>> indicate how the size is being set.  I suspect that calculating the
>>> "relevant module" in that manner and then looking up output-scale
>>> in it
>>> might do the trick.  But I haven't really understood the output scale
>>> business anyway.  It's not clear to me how it works in every
>>> circumstance.
>>>
>> That's not quite what I wanted to hear...  If /you/ say that, it
>> makes me wonder whether a) the entire business is seriously broken
>> by design or b) it's waaay above what I'll ever understand.
>> I agree that looking up the "relevant module" seems to be the
>> missing link.  Anyway, I'll have a look after Aug, 10.
>>
>>
>> Best,
>> Alexander
>>
> Well, my question is this. If I can do something like:
>
> #(set-global-staff-size 18)
>
> \paper {
>  #(define fonts (make-pango-font-tree ... (/ staff-height pt 20)))
> }
>
> where staff-height gets referenced _outside_ of the
> set-global-staff-size call, then why can't we just reference it
> directly within the make-pango-font-tree syntax? It appears that the
> variable/property is stored somewhere, but where? and why can I
> reference it, but make-pango-font-tree can't?

Well, if make-pango-font-tree puts itself in your shoes, it may.
Putting itself in your shoes might mean
(/ (module-ref (current-module) 'staff-height)
   (module-ref (current-module) 'pt))
instead of staff-height, and that does not protect against
make-pango-font-tree being used outside of your shoes...

-- 
David Kastrup

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

Re: Add an expert font tree interface (issue 108700043 by perpeduumimmob...@gmail.com)

[Janek Warchoł]

2014-08-01 12:04 GMT+02:00  :
> The user interface is simply an optional argument (default 1) in the
> font-spec-list. [...]

Ah, so it's up to the user to provide scaling factors.  I thought that
there is some code measuring height of the x letter and scaling the
font accordingly :)

Ok, now i see that you've already written that in

>> > No attempt has been made for
>> > auto-detection of the x-height of a font; I guess that would require
>> > delving into the C++-Pango parts, which is above my threshold.

(but i've misunderstood it as something else).

best,
Janek

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

Re: Rename calc-property-by-copy to copy-property-from-event (issue 122750044 by janek.lilyp...@gmail.com)

[dak]

https://codereview.appspot.com/122750044/diff/20001/scm/output-lib.scm
File scm/output-lib.scm (right):

https://codereview.appspot.com/122750044/diff/20001/scm/output-lib.scm#newcode1114
scm/output-lib.scm:1114: (export grob::calc-property-by-copy)
You can just use define-public here.  It is only define-public with
curried definition syntax (like the immediately preceding define) that
is broken through much of Guile-2.0.

But since it only concerns the syntax of the definition rather than the
actual result of this definition, you don't need to jump through the
same hoops for a plain (define-public x y) even if y has been defined
using (define ((y ...

https://codereview.appspot.com/122750044/

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

Re: thoughts on changing \magnifyMusic, please comment

[Urs Liska]

Am 02.08.2014 11:35, schrieb Janek Warchoł:

Now with requests for absolute and relative versions, as
>well as this:
>
>   \temporary \magnifyStaff 1.3
>   ...
>   \undo \magnifyStaff 1.3
>
>...I'm starting to wonder how much of this is really
>necessary.  Can anyone provide an actual use case to justify
>accommodating either of these requests?

I admit that i don't have an actual use case.  I expect that crazy
composers like Mike (hello Mike! :)) could want to make the staff
progressively bigger and bigger each measure, for example as a fancy
way of indicating global crescendo sustained over many measures.  But
that's just a speculation.


>


I don't have concrete examples either, but I can think of two practical 
use cases:
Temporarily changing staff size may be useful in pedagogical sheets. And 
you could make it useful when writing "dialogue" like parts, i.e. when 
two or more instruments or singers sing/play alternatingly. Then it may 
be helpful for sight-reading when your own part is on maginfied parts of 
the staff.


Urs


--
Urs Liska
www.openlilylib.org

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

Allow changing of notation fonts (issue 115590043 by lilyli...@googlemail.com)

[lilyliska]

Reviewers: ,

Message:
This is the current state of Abraham's approach to make music fonts
switchable. The patch is incomplete in a few senses, but Abraham wants
an official review for that current state:

- there's no documentation
  -> We'll take care of that once the user interface
 has been fixed
- there's no convert-ly rule
  -> ditto, this should pose no problems.
- the patch will somehow have to be integrated with
  Alexander's work on the text font selection interface,
  but Alexander considers it not too problematic.

See
http://lists.gnu.org/archive/html/lilypond-user/2014-08/msg00016.html

Description:
Allow changing of notation fonts

This commit changes the behaviour of make-pango-font-tree in the
following ways:

- Make all arguments optional key/value pairs
  keeping the current default values (emmentaler/Century Schoolbook)
- Allow changing of music fonts too.

Currently alternative music fonts have to be present in the font
directory besides Emmentaler fonts, and they have to be manually
installed.
But now there are a number of alternative and compatible fonts
available.

Please review this at https://codereview.appspot.com/115590043/

Affected files (+42, -6 lines):
  M scm/font.scm


Index: scm/font.scm
diff --git a/scm/font.scm b/scm/font.scm
index  
867612ae11529c3426a795498a6dc5168481f427..e177a055edb31ca56bcc4030718b2b759da75c4a  
100644

--- a/scm/font.scm
+++ b/scm/font.scm
@@ -147,7 +147,7 @@

 ;; Each size family is a vector of fonts, loaded with a delay.  The
 ;; vector should be sorted according to ascending design size.
-(define-public (add-music-fonts node name family design-size-alist factor)
+(define-public (add-music-fonts node family name brace design-size-alist  
factor)

   "Set up music fonts.

 Arguments:
@@ -156,12 +156,15 @@ Arguments:
 @var{node} is the font tree to modify.

 @item
+@var{family} is the family name of the music font.
+
+@item
 @var{name} is the basename for the music font.
 @file{@var{name}-.otf} should be the music font,
-@file{@var{name}-brace.otf} should have piano braces.

 @item
-@var{family} is the family name of the music font.
+@var{brace} is the basename for the brace font.
+@file{@var{brace}-brace.otf} should have piano braces.

 @item
 @var{design-size-alist} is a list of @code{(rounded . designsize)}.
@@ -199,7 +202,7 @@ used.  This is used to select the proper design size  
for the text fonts.

)))
  (fetaBraces ,(ly:pt 20.0)
  #(,(delay (ly:system-font-load
-(format #f "~a-brace" name)
+(format #f "~a-brace" brace)
  )))

 (define-public (add-pango-fonts node lily-family family factor)
@@ -229,9 +232,40 @@ used.  This is used to select the proper design size  
for the text fonts.

   (add-node 'italic 'normal)
   (add-node 'italic 'bold))

+; This function allows the user to change the specific fonts, leaving  
others

+; to the default values. This way, "make-pango-font-tree"'s syntax doesn't
+; have to change from the user's perspective.
+;
+; Usage:
+;   \paper {
+; #(define fonts
+;   (set-global-fonts
+;#:music "gonville"  ; (the main notation font)
+;#:roman "FreeSerif" ; (the main/serif text font)
+;   ))
+;   }
+;
+; Leaving out "#:brace", "#:sans", and "#:typewriter" leave them at
+; "emmentaler", "sans-serif", and "monospace", respectively. All fonts are
+; still accesible through the usual scheme symbols: 'feta, 'roman, 'sans,  
and

+; 'typewriter.
+(define*-public (set-global-fonts #:key
+  (music "emmentaler")
+  (brace "emmentaler")
+  (roman "Century Schoolbook L")
+  (sans "sans-serif")
+  (typewriter "monospace")
+  (factor 1))
+  (let ((n (make-font-tree-node 'font-encoding 'fetaMusic)))
+(add-music-fonts n 'feta music brace feta-design-size-mapping factor)
+(add-pango-fonts n 'roman roman factor)
+(add-pango-fonts n 'sans sans factor)
+(add-pango-fonts n 'typewriter typewriter factor)
+n))
+
 (define-public (make-pango-font-tree roman-str sans-str typewrite-str  
factor)

   (let ((n (make-font-tree-node 'font-encoding 'fetaMusic)))
-(add-music-fonts n "emmentaler" 'feta feta-design-size-mapping factor)
+(add-music-fonts n 'feta "emmentaler" "emmentaler"  
feta-design-size-mapping factor)

 (add-pango-fonts n 'roman roman-str factor)
 (add-pango-fonts n 'sans sans-str factor)
 (add-pango-fonts n 'typewriter typewrite-str factor)
@@ -240,7 +274,9 @@ used.  This is used to select the proper design size  
for the text fonts.

 (define-public (make-century-schoolbook-tree factor)
   (make-pango-font-tree
"Century Schoolbook L"
-   "sans-serif" "monospace" factor))
+   "sans-serif"
+   "monospace"
+   factor))

 (define-public all-text-font-encodings
   '(latin1))



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

Re: Allow changing of notation fonts (issue 115590043 by lilyli...@googlemail.com)

[Abraham Lee]

On Sat, Aug 2, 2014 at 10:40 AM, lilyli...@googlemail.com wrote:

Reviewers: ,

Message:
This is the current state of Abraham's approach to make music fonts
switchable. The patch is incomplete in a few senses, but Abraham wants
an official review for that current state:

- there's no documentation
  -> We'll take care of that once the user interface
 has been fixed
- there's no convert-ly rule
  -> ditto, this should pose no problems.
- the patch will somehow have to be integrated with
  Alexander's work on the text font selection interface,
  but Alexander considers it not too problematic.

See
http://lists.gnu.org/archive/html/lilypond-user/2014-08/msg00016.html

Description:
Allow changing of notation fonts

This commit changes the behaviour of make-pango-font-tree in the
following ways:

- Make all arguments optional key/value pairs
  keeping the current default values (emmentaler/Century Schoolbook)
- Allow changing of music fonts too.

Currently alternative music fonts have to be present in the font
directory besides Emmentaler fonts, and they have to be manually
installed.
But now there are a number of alternative and compatible fonts
available.

Please review this at https://codereview.appspot.com/115590043/

Affected files (+42, -6 lines):
  M scm/font.scm


Index: scm/font.scm
diff --git a/scm/font.scm b/scm/font.scm
index 
867612ae11529c3426a795498a6dc5168481f427..e177a055edb31ca56bcc4030718b2b759da75c4a 
100644

--- a/scm/font.scm
+++ b/scm/font.scm
@@ -147,7 +147,7 @@

 ;; Each size family is a vector of fonts, loaded with a delay.  The
 ;; vector should be sorted according to ascending design size.
-(define-public (add-music-fonts node name family design-size-alist 
factor)
+(define-public (add-music-fonts node family name brace 
design-size-alist factor)

   "Set up music fonts.

 Arguments:
@@ -156,12 +156,15 @@ Arguments:
 @var{node} is the font tree to modify.

 @item
+@var{family} is the family name of the music font.
+
+@item
 @var{name} is the basename for the music font.
 @file{@var{name}-.otf} should be the music font,
-@file{@var{name}-brace.otf} should have piano braces.

 @item
-@var{family} is the family name of the music font.
+@var{brace} is the basename for the brace font.
+@file{@var{brace}-brace.otf} should have piano braces.

 @item
 @var{design-size-alist} is a list of @code{(rounded . designsize)}.
@@ -199,7 +202,7 @@ used.  This is used to select the proper design 
size for the text fonts.

)))
  (fetaBraces ,(ly:pt 20.0)
  #(,(delay (ly:system-font-load
-(format #f "~a-brace" name)
+(format #f "~a-brace" brace)
  )))

 (define-public (add-pango-fonts node lily-family family factor)
@@ -229,9 +232,40 @@ used.  This is used to select the proper design 
size for the text fonts.

   (add-node 'italic 'normal)
   (add-node 'italic 'bold))

+; This function allows the user to change the specific fonts, 
leaving others
+; to the default values. This way, "make-pango-font-tree"'s syntax 
doesn't

+; have to change from the user's perspective.
+;
+; Usage:
+;   \paper {
+; #(define fonts
+;   (set-global-fonts
+;#:music "gonville"  ; (the main notation font)
+;#:roman "FreeSerif" ; (the main/serif text font)
+;   ))
+;   }
+;
+; Leaving out "#:brace", "#:sans", and "#:typewriter" leave them at
+; "emmentaler", "sans-serif", and "monospace", respectively. All 
fonts are
+; still accesible through the usual scheme symbols: 'feta, 'roman, 
'sans, and

+; 'typewriter.
+(define*-public (set-global-fonts #:key
+  (music "emmentaler")
+  (brace "emmentaler")
+  (roman "Century Schoolbook L")
+  (sans "sans-serif")
+  (typewriter "monospace")
+  (factor 1))
+  (let ((n (make-font-tree-node 'font-encoding 'fetaMusic)))
+(add-music-fonts n 'feta music brace feta-design-size-mapping 
factor)

+(add-pango-fonts n 'roman roman factor)
+(add-pango-fonts n 'sans sans factor)
+(add-pango-fonts n 'typewriter typewriter factor)
+n))
+
 (define-public (make-pango-font-tree roman-str sans-str 
typewrite-str factor)

   (let ((n (make-font-tree-node 'font-encoding 'fetaMusic)))
-(add-music-fonts n "emmentaler" 'feta feta-design-size-mapping 
factor)
+(add-music-fonts n 'feta "emmentaler" "emmentaler" 
feta-design-size-mapping factor)

 (add-pango-fonts n 'roman roman-str factor)
 (add-pango-fonts n 'sans sans-str factor)
 (add-pango-fonts n 'typewriter typewrite-str factor)
@@ -240,7 +274,9 @@ used.  This is used to select the proper design 
size for the text fonts.

 (define-public (make-century-schoolbook-tree factor)
   (make-pango-font-tree
"Century Schoolbook L"
-   "sans-serif" "monospace" factor))
+   "sans-serif"
+   "monospace"
+   factor))

 (define-public all-text-font-encodings
   '(latin1))



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://li

Git push error: Unpack failed

[Colin Campbell]

Attempting to push a single patch, using the directions in CG 3.4.11, I 
get the console output appended. I haven't attempted anything since, and 
would be grateful for guidance from the gurus. Online research suggests 
either permission errors on the savannah repo, space issues at savannah, 
or corruption either locally or on the remote. Both my local repo and 
savannah seem perfectly normal when I look around with gitk, so I'm 
turning to the assembled wisdom for the next steps I need to take.


Cheers,
Colin

colin@Sherlock ~/lilypond-git (dev/local_working)$ git checkout staging
Branch staging set up to track remote branch staging from origin.
Switched to a new branch 'staging'
colin@Sherlock ~/lilypond-git (staging)$ git pull -r
remote: Counting objects: 825, done.
remote: Compressing objects: 100% (170/170), done.
remote: Total 494 (delta 413), reused 390 (delta 324)
Receiving objects: 100% (494/494), 351.62 KiB | 359.00 KiB/s, done.
Resolving deltas: 100% (413/413), completed with 287 local objects.
From git://git.sv.gnu.org/lilypond
   a577554..f4abbff  staging-> origin/staging
   a577554..f4abbff  master -> origin/master
   8a50484..730d4eb  translation -> origin/translation
First, rewinding head to replay your work on top of it...
Fast-forwarded staging to f4abbfff5f0d985a457e15586dbcc3ae473b0dee.
colin@Sherlock ~/lilypond-git (staging)$ git merge local_working
merge: local_working - not something we can merge
colin@Sherlock ~/lilypond-git (staging)$ git merge dev/local_working
Merge made by the 'recursive' strategy.
 Documentation/web/introduction.itexi | 84 
+---

 1 file changed, 41 insertions(+), 43 deletions(-)
colin@Sherlock ~/lilypond-git (staging)$ gitk
colin@Sherlock ~/lilypond-git (staging)$ git push origin staging
Counting objects: 34, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 1.23 KiB | 0 bytes/s, done.
Total 8 (delta 6), reused 0 (delta 0)
error: unpack failed: unpack-objects abnormal exit
To git://git.sv.gnu.org/lilypond.git
 ! [remote rejected] staging -> staging (n/a (unpacker error))
error: failed to push some refs to 'git://git.sv.gnu.org/lilypond.git'

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

Re: Git push error: Unpack failed

[Janek Warchoł]

Hi,

2014-08-02 20:32 GMT+02:00 Colin Campbell :
> Attempting to push a single patch, using the directions in CG 3.4.11, I get
> the console output appended. I haven't attempted anything since, and would
> be grateful for guidance from the gurus. Online research suggests either
> permission errors on the savannah repo, space issues at savannah, or
> corruption either locally or on the remote. Both my local repo and savannah
> seem perfectly normal when I look around with gitk, so I'm turning to the
> assembled wisdom for the next steps I need to take.

for what it's worth, i've been able to push a private branch to
dev/janek/issue-3186 moments ago.

Maybe it was a temporary error?  I think that trying to push again in
a few minutes should be a safe thing to do.
You may also check your repository with 'git fsck' (note that
"dangling commit/blob" messages don't usually mean anything bad).

best,
Janek

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

Re: Rename calc-property-by-copy to copy-property-from-event (issue 122750044 by janek.lilyp...@gmail.com)

[dak]

On 2014/08/02 18:32:41, janek wrote:

use simpler syntax


Looks good.  Looking at the name grob::copy-property-from-event, I think
that grob::property-from-event is shorter but probably equally
descriptive.  Though perhaps we have a number of others starting with
copy- already.

Your call.

https://codereview.appspot.com/122750044/

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

Re: Remove tied accidentals after line-breaking (issue 46060045)

[k-ohara5a5a]

LGTM

https://codereview.appspot.com/46060045/

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

Re: Remove tied accidentals after line-breaking (issue 46060045)

[dak]

On 2014/08/02 18:56:19, Keith wrote:

LGTM


Cannot find the corresponding Google Code issue.

https://codereview.appspot.com/46060045/

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

Re: Remove tied accidentals after line-breaking (issue 46060045)

[pkx166h]

On 2014/08/02 19:26:11, dak wrote:

On 2014/08/02 18:56:19, Keith wrote:
> LGTM



Cannot find the corresponding Google Code issue.


http://code.google.com/p/lilypond/issues/detail?id=3646

https://codereview.appspot.com/46060045/

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

Re: updated doc snippets on LSR

[Phil Holmes]

- Original Message - 
From: "Keith E OHara" 

To: 
Cc: "Phil Holmes" 
Sent: Saturday, August 02, 2014 9:44 PM
Subject: updated doc snippets on LSR



Two snippets used a function make-simple-closure.
No-one understands the purpose of that function anymore, so we stopped 
recommending it in the docs with issue 3993.


I re-entered these two snippets in form that avoids make-simple closure
http://lsr.di.unimi.it/LSR/Item?id=948
http://lsr.di.unimi.it/LSR/Item?id=949

The function still works, so either version of the snippets works with 
recent versions of LilyPond



I'm not certain what needs to be done here.  Is it a simple LSR import or 
something more fundamental?


--
Phil Holmes 



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

updated doc snippets on LSR

[Keith E OHara]

Two snippets used a function make-simple-closure.
No-one understands the purpose of that function anymore, so we stopped  
recommending it in the docs with issue 3993.


I re-entered these two snippets in form that avoids make-simple closure
http://lsr.di.unimi.it/LSR/Item?id=948
http://lsr.di.unimi.it/LSR/Item?id=949

The function still works, so either version of the snippets works with  
recent versions of LilyPond



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

Re: [SPAM] Re: Fonts for testing

[Urs Liska]

Am 03.08.2014 00:26, schrieb Abraham Lee:

On Sat, Aug 2, 2014 at 1:46 PM, Urs Liska  wrote:

Hi Abraham, as fonts.openlilylib.org is "Under construction" you
should provide a download link for the fonts (or at least one plus
Gonville (for the braces), so others can actually test the patch.
Please send the link to the -devel list and possibly add it as a
comment to https://code.google.com/p/lilypond/issues/detail?id=4047
Best Urs
--
Urs Liska www.openlilylib.org 


Done.


Thanks.


You must have missed this post (I guess I didn't send it to the
-devel list at the time):


I _did_ read this, but
a) I thought it should be explicitly referenced in the context of the review
b) I didn't recall exactly where I read it.

Best
Urs



http://lilypond.1069038.n5.nabble.com/Where-to-Download-the-New-Music-Fonts-tp165035p165044.html

Thanks for your help! It's nice to work with so many agreeable people.
-Abraham



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

Re: Git push error: Unpack failed

[Colin Campbell]

On 14-08-02 12:41 PM, Janek Warchoł wrote:

Hi,

2014-08-02 20:32 GMT+02:00 Colin Campbell :

Attempting to push a single patch, using the directions in CG 3.4.11, I get
the console output appended. I haven't attempted anything since, and would
be grateful for guidance from the gurus. Online research suggests either
permission errors on the savannah repo, space issues at savannah, or
corruption either locally or on the remote. Both my local repo and savannah
seem perfectly normal when I look around with gitk, so I'm turning to the
assembled wisdom for the next steps I need to take.

for what it's worth, i've been able to push a private branch to
dev/janek/issue-3186 moments ago.

Maybe it was a temporary error?  I think that trying to push again in
a few minutes should be a safe thing to do.
You may also check your repository with 'git fsck' (note that
"dangling commit/blob" messages don't usually mean anything bad).

best,
Janek



Thanks for the try, Janek! It's still happening, after a git pull -r . 
Gitk shows one commit difference. Git fsck ran with no errors reported.


Still baffled,
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

Re: Git push error: Unpack failed

[Colin Campbell]

On 14-08-02 05:26 PM, Colin Campbell wrote:


Thanks for the try, Janek! It's still happening, after a git pull -r . 
Gitk shows one commit difference. Git fsck ran with no errors reported.


Still baffled,
Colin



Less baffled now: the problem was in my local ~/lilypond-git/.git/config 
file, where I had the wrong protocol on the [remote "origin" ] URL: git 
instead of ssh. Apologies for the noise and some hope that this might 
help others doing major housecleaning on their disks.


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