On Tue, 24 Apr 2012 23:29:02 -0700, wrote:
http://codereview.appspot.com/6035053/diff/16001/lily/beam.cc
File lily/beam.cc (right):
http://codereview.appspot.com/6035053/diff/16001/lily/beam.cc#newcode1328
lily/beam.cc:1328: return scm_from_double (0.0);
On 2012/04/25 06:21:29, Keith wrote:
I
http://codereview.appspot.com/6035053/diff/16001/lily/beam.cc
File lily/beam.cc (right):
http://codereview.appspot.com/6035053/diff/16001/lily/beam.cc#newcode1328
lily/beam.cc:1328: return scm_from_double (0.0);
On 2012/04/25 06:21:29, Keith wrote:
It would seem we do not want an early return i
The function being patched is the pure-alternative to a
chained-offset-callback to the original Y-position
callback for rests (Rest::y_offset_callback).
I cannot follow the data between C and Scheme well enough to understand
what this function should return if it needs to bail out early.
The prob
On 2012/04/21 16:10:09, dak wrote:
The "cleanup" would seem to break layout totally.
http://permalink.gmane.org/gmane.comp.gnu.lilypond.general/71476>
That's disappointing. The property 'previous_offset' sometimes has
values comparable to the page height. On the early returns I'll return
On 2012/04/15 20:06:55, Keith wrote:
On 2012/04/15 16:45:54, Keith wrote:
>
> An improvement would be to round-to-larger
Done, along with other cleanup following the similar function
rest_collision_callback()
The "cleanup" would seem to break layout totally.
http://permalink.gmane.org/gmane
On 2012/04/15 16:45:54, Keith wrote:
An improvement would be to round-to-larger
Done, along with other cleanup following the similar function
rest_collision_callback()
http://codereview.appspot.com/6035053/
___
lilypond-devel mailing list
lilypond-
beam.cc:pure-rest-collision-callback Place on staff lines; issue 2468
Please review this at http://codereview.appspot.com/6035053/
Affected files:
M lily/beam.cc
Index: lily/beam.cc
diff --git a/lily/beam.cc b/lily/beam.cc
index
0cfc3e193cba6b3feea911abb09
On 2012/04/15 15:20:13, Graham Percival wrote:
wow, looks very nice and simple. I vote for pushing immediately, but
please
wait for at least one other such vote (or a countdown).
if max/min trigger, rint is applied to some rest_max_pos. It would
appear that it should rather apply only to th
wow, looks very nice and simple. I vote for pushing immediately, but
please wait for at least one other such vote (or a countdown).
http://codereview.appspot.com/6035053/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mai
[EMAIL PROTECTED] writes:
>
> How about an upgrade to autoconf 2.5 ?
>
There are some bugs in autoconf 2.5 that can't be worked around. We're
still waiting for their response to our bugreport.
--
Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.cs.uu.nl/~hanwen
__
Han-Wen Nienhuys wrote:
I think this was already fixed in 1.6.3, can you upgrade to 1.6.6 and
see if that fixes the problem?
(this refers to the botched spacing)
I fixed the problem with rest dots in CVS (1.6 branch).
I just upgraded to the most recent cvs version and
everything works fine n
[EMAIL PROTECTED] writes:
> [EMAIL PROTECTED] writes:
> > Han-Wen Nienhuys wrote:
> >
> > > The DVI has mismatched fonts, so my guess is that it is not a recent
> > > version of lily. Which version of lily did you use, and can you send
> > > the corresponding .ly file?
> >
> > I used version 1.
[EMAIL PROTECTED] writes:
> Han-Wen Nienhuys wrote:
>
> > The DVI has mismatched fonts, so my guess is that it is not a recent
> > version of lily. Which version of lily did you use, and can you send
> > the corresponding .ly file?
>
> I used version 1.6.0
I think this was already fixed in 1.6
Han-Wen Nienhuys wrote:
The DVI has mismatched fonts, so my guess is that it is not a recent
version of lily. Which version of lily did you use, and can you send
the corresponding .ly file?
I used version 1.6.0
The source.ly is attached
regards Klaus
\header {
title = "Praise be to God"
[EMAIL PROTECTED] writes:
> Han-Wen Nienhuys wrote:
> > Although I can imagine that this could happen, your example looks fine
> > to me, so I think I'm missing something. Can you explain more clearly
> > what spacing you think is bad?
>
> I'll just give you both the dvi of the entire piece,
> o
Han-Wen Nienhuys wrote:
Although I can imagine that this could happen, your example looks fine
to me, so I think I'm missing something. Can you explain more clearly
what spacing you think is bad?
I'll just give you both the dvi of the entire piece,
one produced with the old code, one with the n
[EMAIL PROTECTED] writes:
> Hi,
>
> the current code in lily/rest-collision.cc which kills
> the rests of the same measure that are supernumerary
> according to the maximum-rest-count variable can lead to
> very bad spacing.
>
> This effect seem only to rests of a duration of 2 or more.
> An extr
st is alphabetically ordered.
@item @email{rune@@zedeler.dk, Rune Zedeler}
Drum notation, beaming and auto-accidental code. Font
updates. Miscellaneous fixes.
+@item @email{klaus_zimmermann@@gmx.de, Klaus Zimmermann}
+minor fix in rest-collision.
@end itemiz
I cannot begin to tell you how disappointed I was to finish this simple
two part arrangement, which does considerable violence to Haendel but
is made very easy for beginners, to find that the augmentation dots are
not down when \stemDowm is in effect. What possible reason could there
be not to
19 matches
Mail list logo
