Re: Issue 68 in lilypond: certain \paper variables put music at the bottom of the page (easy workaround)

Comment #8 on issue 68 by joeneeman: certain \paper variables put music at the bottom of the page (easy workaround) http://code.google.com/p/lilypond/issues/detail?id=68 I'm happy to just close this (but then I was happy to close it 2 years ago...) -- You received this message because you

Re: Lyrics break estimation of vertical spacing

Looking at Page_breaking::min_page_count(), I am thinking > about the correct generalization of the concept of "rod_height", > so that we would still have one "current position", but two > "current bottom edges" (so the next current position is calculated > by juxtaposing the next system's tw

Re: Lyrics break estimation of vertical spacing

First of all, thank you Joe for all the explanations -- now that it has dawned on me what the source of confusion was, it all makes sense.  Thanks!!   I am now thinking about how to implement this TODO best. > One idea that immediately comes to mind, is to replace the > unified heights with be

Re: Issue 1045 in lilypond: Regression: dead-notes.ly: too much dead notes on tab staff

Comment #3 on issue 1045 by Carl.D.Sorensen: Regression: dead-notes.ly: too much dead notes on tab staff http://code.google.com/p/lilypond/issues/detail?id=1045 Sorry about the mistake. I should have checked the 2.13.16 release first. Thanks for cleaning up after me. -- You received this m

Re: Lyrics break estimation of vertical spacing

On Wed, 24 Mar 2010 18:15:45 -0400, Boris Shingarov wrote: Hmm, let me understand this better. > Does it mean that Constrained_breaking::fill_line_details() gets > called before the line breaks are calculated, and then again after   Oh, now I understand why!!!  The hack addresses the space be

Re: Lyrics break estimation of vertical spacing

Right, the positions of the staff lines relative to each other are not > yet computed, so each extent is relative to its own staff. Hmm, let me understand this better. Does it mean that Constrained_breaking::fill_line_details() gets called before the line breaks are calculated, and then again a

Re: Lyrics break estimation of vertical spacing

On Wed, 24 Mar 2010 14:19:21 -0700, Joe Neeman wrote: Right, but in align-interface.cc:118, we throw away that unite()d extent > in favour of a begin_of_line_extent and a rest_of_line_extent.   But that, IIUC, is only happening one level (of the grob tree) above, when it's too late, no?  That

Re: Lyrics break estimation of vertical spacing

On Wed, 2010-03-24 at 16:08 -0400, Boris Shingarov wrote: > > The skylines are used as part of VerticalAlignment, to figure out how > > far apart the children of VerticalAlignment (ie. VerticalAxisGroups for > > staves, lyrics, etc) need to be. Once we compute the translations of the > > chil

Re: Lyrics break estimation of vertical spacing

On Wed, 24 Mar 2010 16:08:51 -0400, Boris Shingarov wrote: What happens in reality, is that pure_height() of the VerticalAxisGroup, > calling ly:hara-kiri-group-spanner::y-extent in Scheme land, > calling back Hara_kiri_group_spanner::pure_height(), ultimately > ends up in Axis_group_interfa

Re: Lyrics break estimation of vertical spacing

The skylines are used as part of VerticalAlignment, to figure out how > far apart the children of VerticalAlignment (ie. VerticalAxisGroups for > staves, lyrics, etc) need to be. Once we compute the translations of the > children of VerticalAlignment, we can compute the height of > VerticalAl

Re: Issue 1045 in lilypond: Regression: dead-notes.ly: too much dead notes on tab staff

Updates: Status: Fixed Labels: fixed_2_13_17 Comment #2 on issue 1045 by percival.music.ca: Regression: dead-notes.ly: too much dead notes on tab staff http://code.google.com/p/lilypond/issues/detail?id=1045 Technically, this is not at all invalid. The 2.13.16 release contain

Re: Issue 139 in lilypond: tie misinterpreted as a slur

Updates: Status: Accepted Comment #11 on issue 139 by percival.music.ca: tie misinterpreted as a slur http://code.google.com/p/lilypond/issues/detail?id=139 LOLwut? "Verified" means "a programmer said it was fixed, and an independant person agrees that the issue was fixed". It doesn'

Re: Issue 139 in lilypond: tie misinterpreted as a slur

Updates: Status: Verified Comment #10 on issue 139 by jameseli...@googlemail.com: tie misinterpreted as a slur http://code.google.com/p/lilypond/issues/detail?id=139 (No comment was entered for this change.) -- You received this message because you are listed in the owner or CC field

Re: Issue 1045 in lilypond: Regression: dead-notes.ly: too much dead notes on tab staff

Updates: Status: Invalid Comment #1 on issue 1045 by Carl.D.Sorensen: Regression: dead-notes.ly: too much dead notes on tab staff http://code.google.com/p/lilypond/issues/detail?id=1045 Thanks for finding this, but this has already been fixed in 2.13.17. I've attached the output from

Re: Hidden note erases dotted note from chord in the first voice

У вт, 2010-03-23 у 18:51 +, Anthony пише: > > I'm not top posting. Nope. Not me. Thank You! :-) Added as 1048: http://code.google.com/p/lilypond/issues/detail?id=1048 > I wouldn't expect a hidden note to be able to erase the dot from a dotted note > from a different voice but that is what c

Issue 1048 in lilypond: Dot next to visible notehead disappears when this notehead is merged with hidden dotted note

Status: Accepted Owner: Labels: Type-Defect Priority-Medium New issue 1048 by brownian.box: Dot next to visible notehead disappears when this notehead is merged with hidden dotted note http://code.google.com/p/lilypond/issues/detail?id=1048 Reported by Anthony, http://lists.gnu.org/archi

Re: Issue 1031 in lilypond: constantly-changing input/regression/rest-collision-beam-note.ly

Comment #3 on issue 1031 by percival.music.ca: constantly-changing input/regression/rest-collision-beam-note.ly http://code.google.com/p/lilypond/issues/detail?id=1031 Issue 1047 has been merged into this issue. -- You received this message because you are listed in the owner or CC fields of

Re: Issue 1047 in lilypond: Regression: rest-collision-beam-note.ly: rest now collides with beam?... or it does not?..

Updates: Status: Duplicate Mergedinto: 1031 Comment #1 on issue 1047 by percival.music.ca: Regression: rest-collision-beam-note.ly: rest now collides with beam?... or it does not?.. http://code.google.com/p/lilypond/issues/detail?id=1047 Duplicate of 1031. -- You received t

Re: Issue 1046 in lilypond: \deadNote ( used in ‘dead-notes.ly’ regtest) is not d ocumented

Updates: Labels: -Priority-High Priority-Critical Comment #1 on issue 1046 by percival.music.ca: \deadNote (used in ‘dead-notes.ly’ regtest) is not documented http://code.google.com/p/lilypond/issues/detail?id=1046 This could be considered part of 989, but I have no objection to havin

Issue 1047 in lilypond: Regression: rest-collision-beam-note.ly: rest now collides with beam?... or it does not?..

Status: Accepted Owner: Labels: Regression Type-Collision Priority-Medium New issue 1047 by brownian.box: Regression: rest-collision-beam-note.ly: rest now collides with beam?... or it does not?.. http://code.google.com/p/lilypond/issues/detail?id=1047 Something strange as for me: Pictu

Issue 1046 in lilypond: \deadNote (used i n ‘dead-notes.ly’ regtest) is not documen ted

Status: Accepted Owner: Labels: Type-Documentation Priority-High New issue 1046 by brownian.box: \deadNote (used in ‘dead-notes.ly’ regtest) is not documented http://code.google.com/p/lilypond/issues/detail?id=1046 I've failed to find documentation for \deadNote in NR "1.1.4 Note heads"

Issue 1045 in lilypond: Regression: dead-notes.ly: too much dead notes on tab staff

Status: Accepted Owner: Labels: Regression Type-Defect Priority-Critical New issue 1045 by brownian.box: Regression: dead-notes.ly: too much dead notes on tab staff http://code.google.com/p/lilypond/issues/detail?id=1045 Just too much dead notes, see the image. As far as i understood, t