LGTM
http://codereview.appspot.com/4293054/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
On Wed, Mar 16, 2011 at 12:44 PM, m...@apollinemike.com
m...@apollinemike.com wrote:
The problem is that Lilypond processes graphical objects before it processes
pagination, making it impossible to know exactly how much space a footnote
will take up when the graphical object is processed.
One
On Mar 19, 2011, at 11:01 AM, Han-Wen Nienhuys wrote:
On Wed, Mar 16, 2011 at 12:44 PM, m...@apollinemike.com
m...@apollinemike.com wrote:
The problem is that Lilypond processes graphical objects before it processes
pagination, making it impossible to know exactly how much space a footnote
On Sat, Mar 19, 2011 at 12:06 PM, m...@apollinemike.com
m...@apollinemike.com wrote:
On Wed, Mar 16, 2011 at 12:44 PM, m...@apollinemike.com
m...@apollinemike.com wrote:
The problem is that Lilypond processes graphical objects before it processes
pagination, making it impossible to know
On Mar 19, 2011, at 11:58 AM, Han-Wen Nienhuys wrote:
On Sat, Mar 19, 2011 at 12:06 PM, m...@apollinemike.com
m...@apollinemike.com wrote:
On Wed, Mar 16, 2011 at 12:44 PM, m...@apollinemike.com
m...@apollinemike.com wrote:
The problem is that Lilypond processes graphical objects before it
On Sat, Mar 19, 2011 at 1:07 PM, m...@apollinemike.com
m...@apollinemike.com wrote:
One way to avoid a two-pass system is to redo the way that top-level markups
are stashed in LilyPond. If LilyPond can re-evaluate these markups after
page breaking is calculated, it can scan to see if their
On Mar 19, 2011, at 12:14 PM, Han-Wen Nienhuys wrote:
On Sat, Mar 19, 2011 at 1:07 PM, m...@apollinemike.com
m...@apollinemike.com wrote:
One way to avoid a two-pass system is to redo the way that top-level markups
are stashed in LilyPond. If LilyPond can re-evaluate these markups after
On Sat, Mar 19, 2011 at 1:20 PM, m...@apollinemike.com
m...@apollinemike.com wrote:
You realize that you may end up in an infinite loop for (rare)
degenerate cases, right? If anything, you should stop after the 2nd
pass.
Good point - I can make the # of passes in the loop a variable w/ the
Am Samstag, 19. März 2011, um 17:27:23 schrieb Han-Wen Nienhuys:
Technically I much prefer the 1 pass solution, although it requires
constraints on how the marks are formatted (with padding space for
small numbers.)
But practically as a publisher of critical editions, I not only prefer, but
I'm happy to announce Schikkers-List v0.0.3 -- the Look Less Ikli
release
Although it's mostly useless, be sure to get it while it's hot
http://lilypond.org/schikkers-list/download/schikkers-list-0.0.3-4.linux-x86.sh
On Sat, Mar 19, 2011 at 11:05:34PM +0100, Reinhold Kainhofer wrote:
Am Samstag, 19. März 2011, um 17:27:23 schrieb Han-Wen Nienhuys:
Technically I much prefer the 1 pass solution, although it requires
constraints on how the marks are formatted (with padding space for
small numbers.)
But
Reviewers: ,
Message:
This is my attempt to get the beam-collision-engraver to handle auto
beams, except...it doesn't work! For some reason, in spite of the fact
that I'm creating AutoBeamStub grobs just fine, the acknowledger in the
beam collision engraver is not picking them up. Can anyone
On 2011/03/18 11:22:11, Trevor Daniels wrote:
LGTM
I like this warning text. Much better.
Trevor
Applying the patch gave the following:
/home/colin/lilypond-git/lily/page-layout-problem.cc: In member function
'void Page_layout_problem::solve_rod_spring_problem(bool)':
Reviewers: Trevor Daniels, Colin Campbell,
Message:
On 2011/03/19 23:37:50, Colin Campbell wrote:
error: expected ';'
Oops. I guess you can't teach an old dog to use a new editor.
Fixed, and I hope people do try it, because this method of suppressing
the repeated warnings changes the output.
LGTM.
I can't think of a case where updating `after' would cause problems -
this seems like a good solution.
http://codereview.appspot.com/4278058/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
On Sat, Mar 19, 2011 at 7:03 PM, mts...@gmail.com wrote:
LGTM.
I can't think of a case where updating `after' would cause problems -
this seems like a good solution.
It might cause problems if pure is true. When the method is called with
pure, it shouldn't cause any side effects. For a
16 matches
Mail list logo
