Re: Lyrics break estimation of vertical spacing
Please forgive me for bumping this discussion, but I was wondering if Valentin, I am sorry I have disappeared from the Lilypond scene for a while. My work on Lilypond development has been temporarily put on the back burner. Right now, we are concentrating on something slightly different: we are working to secure a very large Lilypond-based contract, for a major series of critical editions by a major publisher (I'm not allowed to divulge any details yet including who the publisher is, but I am sure everyone on this list is familiar with the name). IF we are successful, it will mean a radical breakthrough in acceptance for Lilypond. Some time ago, I was talking about how I wanted to transform Lilypond from "a volunteer project with limited resources" (Graham's definition), into a professional open-source project where at least some of the core people can afford to spend non-trivial amounts of time on their passion. I'll come back as soon as I have something to announce (either good or bad). Boris ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing
On Mon, Nov 15, 2010 at 08:40:26AM +0100, David Kastrup wrote: > > In commercial settings, stagnation often means death. With free > software, stagnation mostly means stagnation. > This is one of the strenghts of free software. Another is that over time it becomes tayored to actual users and actual potential users as opposed to those in some salesman's head. If lily had been a commercial product it might well have died years ago. It would be nice to have commercial backing but wheter or not this happens my guess is that lily will become the defacto standard for computer typesetting of music over the next 10 years or so. Bernard ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing
Boris Shingarov writes: > My work on Lilypond development has been temporarily put on the back > burner. Right now, we are concentrating on something slightly > different: we are working to secure a very large Lilypond-based > contract, for a major series of critical editions by a major publisher > (I'm not allowed to divulge any details yet including who the > publisher is, but I am sure everyone on this list is familiar with the > name). IF we are successful, it will mean a radical breakthrough in > acceptance for Lilypond. Some time ago, I was talking about how I > wanted to transform Lilypond from "a volunteer project with limited > resources" (Graham's definition), into a professional open-source > project where at least some of the core people can afford to spend > non-trivial amounts of time on their passion. I'll come back as soon > as I have something to announce (either good or bad). Well, one nice thing with free software development is that you can't really announce something bad (except perhaps for your personal plans). If everything goes wrong with your endeavour, the project is not worse off than before. In commercial settings, stagnation often means death. With free software, stagnation mostly means stagnation. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing
On Wed, Nov 10, 2010 at 2:01 PM, Valentin Villenave wrote: > Please forgive me for bumping this discussion, but I was wondering if > your work on the Lyrics spacing had ever been implemented and merged > into LilyPond. Oh, never mind. Just found it: http://code.google.com/p/lilypond/issues/detail?q=1053 Sorry for the noise! Valentin. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing
On Tue, Mar 30, 2010 at 2:08 PM, Boris Shingarov wrote: > Ok, it's fully functional now. I am going to format and upload a patch. Greetings Boris, Please forgive me for bumping this discussion, but I was wondering if your work on the Lyrics spacing had ever been implemented and merged into LilyPond. If not, do you want me to open a page in the tracker so we don't forget about it? (Unless I'm totally mistaken and it's already been done, in which case I apologize for having missed it.) Cheers, Valentin. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing [now: Issue 1053]
1) what's your gmail account address? 2) try logging out and then back in. When you click on the "Add a comment and make changes" box at the bottom, it should give you a number of options. Cheers, - Graham On Thu, Apr 1, 2010 at 7:51 AM, Boris Shingarov wrote: > Ok, I changed the Owner, but I don't see how I am supposed to change the > Status, etc. Becoming blind? > > On Thu, 1 Apr 2010 07:42:08 0100, Graham Percival wrote: > On Thu, Apr 1, 2010 at 5:23 AM, Boris Shingarov wrote: > > > Ok, so I created Issue 1053. The next logical step would be to assign > this > > > to myself, indicating that I am working on the code to fix it, and link > from > > > the bug report to the patch. Can I do this? > > > > You're now a member of the googlecode lilypond project, so yes. > Please > make it type-enhancement, priority-medium, status-started, > > owner shingarov. > > > Cheers, > > - Graham > > > > > > > ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing [now: Issue 1053]
Ok, I changed the Owner, but I don't see how I am supposed to change the Status, etc. Becoming blind? On Thu, 1 Apr 2010 07:42:08 0100, Graham Percival wrote: On Thu, Apr 1, 2010 at 5:23 AM, Boris Shingarov wrote: > > Ok, so I created Issue 1053. The next logical step would be to assign this > > to myself, indicating that I am working on the code to fix it, and link from > > the bug report to the patch. Can I do this? > > You're now a member of the googlecode lilypond project, so yes. > Please make it type-enhancement, priority-medium, status-started, > owner shingarov. > > Cheers, > - Graham > > ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing [now: Issue 1053]
On Thu, Apr 1, 2010 at 5:23 AM, Boris Shingarov wrote: > Ok, so I created Issue 1053. The next logical step would be to assign this > to myself, indicating that I am working on the code to fix it, and link from > the bug report to the patch. Can I do this? You're now a member of the googlecode lilypond project, so yes. Please make it type-enhancement, priority-medium, status-started, owner shingarov. Cheers, - Graham ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing [now: Issue 1053]
Ok, so I created Issue 1053.
The next logical step would be to assign this to myself, indicating
that I am working on the code to fix it, and link from the bug report
to the patch. Can I do this?
On Wed, 31 Mar 2010 03:47:27 -0400, Boris Shingarov wrote:
Hi Dmytro,
>
> > where it is a bug and where it is not. But if you can provide a minimal
> > example, it will be easier.
>
> The idea definitely is to provide a minimal example. Otherwise, it
> does not count as a bug report, and shouldn't really even be posted on
> the -bug list.
>
> The problem is that our understanding of a bug evolves with time -- it
> is usually very unclear at the beginning.
>
> So was the case with this particular bug. When I first started
> looking at this behavior to try to understand what was causing it, I
> only knew that the low-hanging lyrics were somehow responsible. So I
> named the email, "Lyrics break estimation of vertical spacing". We
> now know exactly what the bug is caused by, and we know that this case
> with lyrics, is only one scenario. The file "lyrics.ly" is one
> minimal example. But the critical ingredient of the bug, is not
> lyrics, but anything hanging very low under the staff. It can be
> lyrics, or it can be notes on ledger lines: this is what my second
> example ("no-lyrics.ly") illustrates. Now, is this name a good name
> for the bug report? No, it's not a good name. But I didn't change
> the subject line on the thread, because it was just a continuation of
> the technical discussion about how to fix the bug.
>
> Boris
>
>
>
>
>
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> http://lists.gnu.org/mailman/listinfo/bug-lilypond
>
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing
On Tue, 30 Mar 2010 08:08:41 -0400, Boris Shingarov wrote: Ok, it's fully functional now. > I am going to format and upload a patch. Hmmm... still overestimates on my "real-life" manuscript, even though several different scenarios (with and withou lyrics) which were restimating, are A-ok now... ok, digging into my hole again to see what breaks this time around... ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing
Ok, it's fully functional now. I am going to format and upload a patch. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing
dynamic_cast? (or maybe my mind is corrupted by 15 years > of Smalltalk, and this is a standard C quirk?) Oops, keyboard failure, obviously meant "C quirk"! ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing
Replace constrained-breaking.cc:461 by
>
> Interval begin_extent = sys->begin_of_line_extent (start, end);
> Interval rest_extent = sys->rest_of_line_extent (start, end);
Ok, experimenting with this, I am inclined to *add* instead of
*replacing*. The extent_ member of Line_details is touched in
many other places, not just Page_breaking (e.g. the spacer also
uses it). I wanted to replace it everywhere first, but now I
think it's probably too intrusive. All I need is access to the
two Intervals in Page_breaking::min_page_count().
Interval
System::begin_of_line_pure_height(Grob *me, vsize start, vsize end)
> {
> System *sys = dynamic_cast (me);
This I have been always wondering about, it's happening
throughout all the Grob code. Why not just take "this" as the
argument? I *am* in class System to bgin with, so why the
dynamic_cast? (or maybe my mind is corrupted by 15 years
of Smalltalk, and this is a standard C quirk?)
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing
On Mon, 2010-03-29 at 21:25 -0400, Boris Shingarov wrote: > Hi Joe, > > > Replace constrained-breaking.cc:461 by > > > > Interval begin_extent = sys->begin_of_line_extent (start, end); > > Interval rest_extent = sys->rest_of_line_extent (start, end); > > > > and replace constrained-breaking.cc:485 by something analogous. > > Btw, it's not clear to me what the inverse_hooke_ should be in this > case -- I am setting it to max of the two extents, it should probably > be calculated later in the game, when we stack the systems on top of > each other at which point we know how long the actual rod is. We'll > see if we get any head ache because of inverse_hooke_. ::shrug:: I doubt it. I don't think any of the spring forces are really significant here. Getting a better height estimate is much more important. Cheers, Joe ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing
On Mon, 2010-03-29 at 20:49 -0400, Boris Shingarov wrote:
> > I'd rather discuss this point now, because I don't like the extension of
> > Interval (and I'd rather you didn't spend a whole lot of time getting it
> > to work if there is a nicer way)
>
> No kidding, neither do I like diluting Interval. One, it is an extremely
> hacky way to do things. Two, it *does* introduce problems all over the
> rest of the code: various idiosyncrasies of C showing up here and
> there, ending up having a donzen of different places fixed already, but
> no one knows how many more will surface. A situation definitely NOT
> to be happy about.
>
> > Replace constrained-breaking.cc:461 by
> >
> > Interval begin_extent = sys->begin_of_line_extent (start, end);
> > Interval rest_extent = sys->rest_of_line_extent (start, end);
>
> Yes, but how do I implement begin_of_line_extent()?
> Grob::pure_height() simply looks up the value of the "Y-extent" property,
> which is a Scheme function, and applies it. The problem that I've been
> struggling with during the past several days, is that this is generic.
>
> Oh wait. Are you saying that System has Axis_group_interface?
Yes.
> So that I can call Axis_group_interface::*_of_line_pure_height() on it?
> Let me try it right now.
No, because *_of_line_pure_height only works properly for
VerticalAxisGroup. What you'll need to do is to write
System:*_of_line_pure_height. For example (typed directly into my mail
client, so it probably won't even compile):
Interval
System::begin_of_line_pure_height(Grob *me, vsize start, vsize end)
{
System *sys = dynamic_cast (me);
Grob *alignment = me->get_vertical_alignment (); // check for null
extract_grob_set (alignment, "elements", staves);
vector offsets = Align_interface::get_minimum_translations (alignment,
staves, Y_AXIS, true, start, end);
Interval ret;
for (vsize i = 0; i < staves.size(); ++i)
{
Interval iv = Axis_group_interface::begin_of_line_pure_height(staves[i],
start);
iv.translate (offsets[i]);
ret.unite (iv);
}
return ret;
}
For more code reuse, it might be better to write one function which
computes both begin_of_line_ and rest_of_line_pure_height.
Cheers,
Joe
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing
Hi Joe, Replace constrained-breaking.cc:461 by > > Interval begin_extent = sys->begin_of_line_extent (start, end); > Interval rest_extent = sys->rest_of_line_extent (start, end); > > and replace constrained-breaking.cc:485 by something analogous. Btw, it's not clear to me what the inverse_hooke_ should be in this case -- I am setting it to max of the two extents, it should probably be calculated later in the game, when we stack the systems on top of each other at which point we know how long the actual rod is. We'll see if we get any head ache because of inverse_hooke_. ::shrug:: ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing
I'd rather discuss this point now, because I don't like the extension of > Interval (and I'd rather you didn't spend a whole lot of time getting it > to work if there is a nicer way) No kidding, neither do I like diluting Interval. One, it is an extremely hacky way to do things. Two, it *does* introduce problems all over the rest of the code: various idiosyncrasies of C showing up here and there, ending up having a donzen of different places fixed already, but no one knows how many more will surface. A situation definitely NOT to be happy about. Replace constrained-breaking.cc:461 by > > Interval begin_extent = sys->begin_of_line_extent (start, end); > Interval rest_extent = sys->rest_of_line_extent (start, end); Yes, but how do I implement begin_of_line_extent()? Grob::pure_height() simply looks up the value of the "Y-extent" property, which is a Scheme function, and applies it. The problem that I've been struggling with during the past several days, is that this is generic. Oh wait. Are you saying that System has Axis_group_interface? So that I can call Axis_group_interface::*_of_line_pure_height() on it? Let me try it right now. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing
On Mon, 2010-03-29 at 17:04 -0400, Boris Shingarov wrote: > > Do we really need this to be included in every Interval? I'd have > > thought that the only data structure that needs to change is > > Line_details. > > Right, but how do you get the actual value in there? Replace constrained-breaking.cc:461 by Interval begin_extent = sys->begin_of_line_extent (start, end); Interval rest_extent = sys->rest_of_line_extent (start, end); and replace constrained-breaking.cc:485 by something analogous. > Hang on a bit, I am debugging the patch, so I can post it and then we > can look at actual code instead of drawing pictures in the air. I'd rather discuss this point now, because I don't like the extension of Interval (and I'd rather you didn't spend a whole lot of time getting it to work if there is a nicer way): intervals are used all over the code and I think they should really remain intervals, rather than hiding additional complexity. If you really need to carry all of the double-intervals around, I think you should create a separate class for them, so they are only used where we want to use them. Cheers, Joe ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing
On Mon, 29 Mar 2010 12:04:42 -0700, Joe Neeman wrote: but I think you don't need to store an > extra version of rod-height. Just define rod-height to measure the > bottom of the last staff (whether that bottom comes from > begin_of_line_extent or rest_of_line_extent). Each time you add a staff, > you just need to see how far it needs to be from the last staff (this is > where the two separate extents come in) and then you increment > rod_height by > > rod_height = distance_between_staves > - min(cur_staff.begin_extent_[DOWN], cur_staff.rest_of_extent_[DOWN]) > min(last_staff.begin_extent_[DOWN], last_staff.rest_of_extent_[DOWN]); Right -- the important point that we need to keep two values indicating how low the last system hangs; whether these two are kept in last_staff.*_extent_, or in two rods, is an implementation detail. Hang on a bit, I am debugging the patch, so I can post it and then we can look at actual code instead of drawing pictures in the air. Boris ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing
Do we really need this to be included in every Interval? I'd have > thought that the only data structure that needs to change is > Line_details. Right, but how do you get the actual value in there? It's filled from calling the Y-extent Scheme function, which can be anything, and in most cases it calls back into C land, but my point is that all these APIs are completely generic, you can't statically tell in which places in code you need the extra interval. My answer to this is an Interval that can be augmented by another Interval, but is in all other respects just an Interval. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing
On Mon, 2010-03-29 at 15:53 -0400, Boris Shingarov wrote: > On Mon, 29 Mar 2010 08:48:35 -0700, Joe Neeman wrote: > > > Keep in mind that a lyric line is the same as a staff to the > > page-breaker. Don't your one-staffers have lyrics? If so, they are > > really two-staffers and so the problem could still be in the > > within-system estimation. > > My one-staffers do have lyrics, but I have overwhelmingly convincing > proof the problem is the between-system estimation. (Also, the > bug exhibits itself even when there are no lyrics, just music on > low ledgers -- the estimator does not know that they go below > the top point of the treble clef on the next line; and because these > are one-liners, the error is very significant (30% of the page is > blank)). > > I've already spent some time writing a patch, and it's almost ready. > The difficult problem is not in the estimator itself -- it's just simple > arithmetic -- but in intervalues crossing the libGuile FFI boundary, > there is a lot of places where the API we are traversing is generic, > and we don't know whether in this instance we are dealing with > a single Interval or with a (begin, rest) pair. > What I did was I generalized "Interval" to be augmentable with > a "rest-of-line" interval, but only if need be. Do we really need this to be included in every Interval? I'd have thought that the only data structure that needs to change is Line_details. Cheers, Joe ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing
On Mon, 29 Mar 2010 08:48:35 -0700, Joe Neeman wrote:
Keep in mind that a lyric line is the same as a staff to the
> page-breaker. Don't your one-staffers have lyrics? If so, they are
> really two-staffers and so the problem could still be in the
> within-system estimation.
My one-staffers do have lyrics, but I have overwhelmingly convincing
proof the problem is the between-system estimation. (Also, the
bug exhibits itself even when there are no lyrics, just music on
low ledgers -- the estimator does not know that they go below
the top point of the treble clef on the next line; and because these
are one-liners, the error is very significant (30% of the page is
blank)).
I've already spent some time writing a patch, and it's almost ready.
The difficult problem is not in the estimator itself -- it's just simple
arithmetic -- but in intervalues crossing the libGuile FFI boundary,
there is a lot of places where the API we are traversing is generic,
and we don't know whether in this instance we are dealing with
a single Interval or with a (begin, rest) pair.
What I did was I generalized "Interval" to be augmentable with
a "rest-of-line" interval, but only if need be. This is hacky in that
it touches the template parametrization in interval.hh:
typedef Interval_t Interval;
becomes:
typedef Interval_t IntervalBase;
and then the class used by everyone is derived from IntervalBase:
class Interval : public IntervalBase { ... }
I'll post the patch shortly.
Boris
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing
On Wed, 2010-03-24 at 22:01 -0400, Boris Shingarov wrote: > 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 begin- and rest-of-line pairs, dragging them > > 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 two top edges against these > current bottom edges). > The spring length, will also remain one. > > Do you agree with this line of thinking, or am I way off with my idea? I don't think you're way off, but I think you don't need to store an extra version of rod-height. Just define rod-height to measure the bottom of the last staff (whether that bottom comes from begin_of_line_extent or rest_of_line_extent). Each time you add a staff, you just need to see how far it needs to be from the last staff (this is where the two separate extents come in) and then you increment rod_height by rod_height += distance_between_staves - min(cur_staff.begin_extent_[DOWN], cur_staff.rest_of_extent_[DOWN]) + min(last_staff.begin_extent_[DOWN], last_staff.rest_of_extent_[DOWN]); The minimums and subtraction looks a bit confusing, but you need to remember that the [DOWN] part of an interval is the smaller number, so the distance from the middle of a staff to the bottom of the staff is -min(begin_extent_[DOWN], rest_of_extent_[DOWN]) Cheers, Joe ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing
On Wed, 2010-03-24 at 19:42 -0400, Boris Shingarov wrote: > 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 > between staves within a system. > Bien sûr it's not doing anything to the space between systems > (mine are one-staffers, so it *does* cause the estimation to be > off *a lot*). > The TODO at constrained-breaking.cc:479 clearly explains it. Keep in mind that a lyric line is the same as a staff to the page-breaker. Don't your one-staffers have lyrics? If so, they are really two-staffers and so the problem could still be in the within-system estimation. > 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 begin- and rest-of-line pairs, dragging them > through all the calls, and unite them at the very end, that is in > constrained-breaking. For one-staff systems, this should be > trivial, but I am not sure how difficult it will be to not break the > general case of multi-staff systems. You would need to separate Line_details.extent_ into Line_details.begin_of_line_extent_ and Line_details.rest_of_line_extent_. I'd suggest writing a System::begin_of_line_extent and System::rest_of_line_extent, which finds the VerticalAlignment, calculates the pure-offsets for the staves and then unifies the appropriate xxx_of_line_extents, with each one at the appropriate offset. Cheers, Joe ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
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 two top edges against these > current bottom edges). Or maybe, we could get by with just adjusting the mutual positions of the two extents when they are unite()'d... trying to think of what this simplification might break: ok, why do we care about the extent, with its [UP] and [DOWN] parts, instead of just the length? - because some of the variables in the layout are relative to the middle line, not the edges of the bounding box. If we vertically shift the begin- and rest- extents for the systems against each other, we no longer have a clear definition of middle line, so we are broken. Am I missing a way to solve this, in a way which is easier than a full implementation of two rods? ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
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 begin- and rest-of-line pairs, dragging them 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 two top edges against these current bottom edges). The spring length, will also remain one. Do you agree with this line of thinking, or am I way off with my idea? ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
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 between staves within a system. Bien sûr it's not doing anything to the space between systems (mine are one-staffers, so it *does* cause the estimation to be off *a lot*). The TODO at constrained-breaking.cc:479 clearly explains it. 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 begin- and rest-of-line pairs, dragging them through all the calls, and unite them at the very end, that is in constrained-breaking. For one-staff systems, this should be trivial, but I am not sure how difficult it will be to not break the general case of multi-staff systems. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
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 after they are known? and at that later stage, sys->pure_height() (constrained-breaking.cc:461) should return a smaller value? but no, it's the "pure" one, i.e. by definition pre-linebreak... ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
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 is, inside Grob::pure_relative_y_coordinate() (grob.cc:456), which follows the Guile call, the returned value from which is already the unify()'ed value, and then we translate *that* value (already too big). I suspect that *may* be where the bug is, but I am not sure. The end result of severe overestimation of height when low-hanging rest-of-line elements are present (such as lyrics or low notes), has been there for a very long time. To me, the whole mechanism of beggining-vs-rest-of-line, is exactly about it, so that means that the whole mechanism is broken (or is there an example where it is working?) But I find it hard to believe that we have been content with living with it for so long. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
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 > > children of VerticalAlignment, we can compute the height of > > VerticalAlignment (and thus the height of System). > > I understand that this is the general idea how it is supposed to be. > 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_interface::cached_pure_height(). > That function, unite()'s the begin_of_line_pure_height() and > the rest_of_line_pure_height(), 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. > which are simply measured from > the middle line of the staff, no translations. Right, the positions of the staff lines relative to each other are not yet computed, so each extent is relative to its own staff. Cheers, Joe ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
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_interface::cached_pure_height(). > That function, unite()'s the begin_of_line_pure_height() and > the rest_of_line_pure_height(), which are simply measured from > the middle line of the staff, no translations. And this is not a caching bug: it doesn't go away if I comment out the first three lines of Axis_group_interface::relative_pure_height(). ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
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 > VerticalAlignment (and thus the height of System). I understand that this is the general idea how it is supposed to be. 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_interface::cached_pure_height(). That function, unite()'s the begin_of_line_pure_height() and the rest_of_line_pure_height(), which are simply measured from the middle line of the staff, no translations. This is the exact point where I am most confused -- what is the supposed result of these translations? So far in the debugger I only see values relative to the middle line; what is the idea what these translations are supposed to be? ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing
On Tue, 2010-03-23 at 22:51 -0400, Boris Shingarov wrote: > > The estimated height for the whole system _should_ take into account the > > fact that the lyrics can be squeezed between the systems. Have a look at > > the comment in align-interface.cc:104 (which should get called as a > > result of sys->pure_height()). The begin_of_line_extent should be zero > > for lyrics, which should allow the lines to be close together in the > > height-estimation procedure. > > Ok, I just got one step forward in the dichotomy of where the bug is. > The begin_of_line_extent is zero. Moreover, the problem is NOT > specific to lyrics, and is observed also if there are low notes. So, I am > concentrating my attention on what's happening in the callers of > get_skylines(). (Need to understand now why these skylines are > part of "translation" and not "height"). 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 VerticalAlignment (and thus the height of System). Cheers, Joe ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing
On Tue, 2010-03-23 at 19:57 -0400, Boris Shingarov wrote:
> > The estimated height for the whole system _should_ take into account the
> > fact that the lyrics can be squeezed between the systems. Have a look at
> > the comment in align-interface.cc:104 (which should get called as a
> > result of sys->pure_height())
>
> Trying to make head or tail of which child is which, and why lyrics do
> increase the pure_height by much, I am now thouroughly confused by
> something else. The height is calculated by unite()'ing the heights
> of all items and all spanners. I started with a trivial example with
> some repeating notes, and no lyrics and nothing else. There is an
> item amounting to [-0.9:0.3], and a spanner amounting to [-7:0].
With the attached .gdbinit file, you can do
ps grob->self_scm_
to see the type of a grob, or
pg grob
to see its type and its properties. That may help you get a better
understanding of what is going on.
> Ok, I step inside the calculation of pure_height for it, and find another
> (one) spanner. Putting a breakpoint inside the for() loop for the items, I
> never hit it. I'd appreciate a three-liner briefly explaining the design of
> this. (The "pure" vs "non-pure" height also seems of mysterious design).
Until the line-breaking is computed, we can't calculate the horizontal
positioning of any grob. pure-height is an _estimate_ of the real height
of the grob ("pure" because it can be computed without causing
side-effects, whereas the actual height usually can't).
Cheers,
Joe
def ps
call ly_display_scm($arg0)
end
def pg
ps $arg0->self_scm_
ps $arg0->immutable_property_alist_
ps $arg0->mutable_property_alist_
end
def pgv
pg $arg0
ps $arg0->object_alist_
end___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing
The estimated height for the whole system _should_ take into account the > fact that the lyrics can be squeezed between the systems. Have a look at > the comment in align-interface.cc:104 (which should get called as a > result of sys->pure_height()). The begin_of_line_extent should be zero > for lyrics, which should allow the lines to be close together in the > height-estimation procedure. Ok, I just got one step forward in the dichotomy of where the bug is. The begin_of_line_extent is zero. Moreover, the problem is NOT specific to lyrics, and is observed also if there are low notes. So, I am concentrating my attention on what's happening in the callers of get_skylines(). (Need to understand now why these skylines are part of "translation" and not "height"). ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing
> The estimated height for the whole system _should_ take into account the > fact that the lyrics can be squeezed between the systems. Have a look at > the comment in align-interface.cc:104 (which should get called as a > result of sys->pure_height()) Trying to make head or tail of which child is which, and why lyrics do increase the pure_height by much, I am now thouroughly confused by something else. The height is calculated by unite()'ing the heights of all items and all spanners. I started with a trivial example with some repeating notes, and no lyrics and nothing else. There is an item amounting to [-0.9:0.3], and a spanner amounting to [-7:0]. Ok, I step inside the calculation of pure_height for it, and find another (one) spanner. Putting a breakpoint inside the for() loop for the items, I never hit it. I'd appreciate a three-liner briefly explaining the design of this. (The "pure" vs "non-pure" height also seems of mysterious design). ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing
On Fri, 19 Mar 2010 17:15:08 -0400, Boris Shingarov wrote:
> As to the call to get_skylines(), now I am really confused. All this
> (get_property("springs-and-rods") resulting in
> Spacing_spanner::set_springs() and all the other things down the road
> being called), happens much earlier than thewhole page layout stage --
> I guess the Y-extent property is stored inside the grob at this earlier
> stage?
Ok, now I understand what's going on here: the get_skylines() does get
called much earlier in the game, but it also is called during
Constrained_breaking::fill_line_details(), the Y-extent function of the
system is the one from Axis_group_interface; that iterates over all
spanners calculating their pure_height(), that goes through another
layer of Axis_group_interface, and that one finaly reaches the
Align_interface.
What this tree of grobs looks like, and what is each grob, I am not
sure how to tell.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing
On Fri, 19 Mar 2010 13:39:36 -0700, Joe Neeman wrote: The begin_of_line_extent should be zero > for lyrics, which should allow the lines to be close together in the > height-estimation procedure. The difficulty of debugging this, is how do I tell which grob is which. They are Scheme pointers, so it is not easy to tell if the current current iteration of the "for" cycle is the one about the lyrics grob. Boris ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing
Hi Joe,
Thanks for the tips, and have a nice and safe trip!
> The estimated height for the whole system _should_ take into account the
> fact that the lyrics can be squeezed between the systems. Have a look at
> the comment in align-interface.cc:104 (which should get called as a
> result of sys->pure_height())
Apparently, the estimated height does not take it into account.
As to the call to get_skylines(), now I am really confused. All this
(get_property("springs-and-rods") resulting in
Spacing_spanner::set_springs() and all the other things down the road
being called), happens much earlier than thewhole page layout stage --
I guess the Y-extent property is stored inside the grob at this earlier
stage?
> The begin_of_line_extent should be zero
> for lyrics, which should allow the lines to be close together in the
> height-estimation procedure.
It looks to me like the correction based on begin_of_line_extent, is
only about the case when the whole previous line is lyrics? I'll step
through get_skylines() in the debugger right now to see what's going on.
Boris
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing
Unfortunately, I'm about to go out of town for the weekend, so I don't
have time right now to follow this up properly. But I've left a couple
of hints below.
On Fri, 2010-03-19 at 11:05 -0400, Boris Shingarov wrote:
> On Wed, 13 Jan 2010 19:37:14 1100, Joe Neeman wrote:
>
> > It's nice to see someone else touching the page-breaking code
>
> The more I dig into it, the more questions I have.
> Back in January, we talked about vertical space estimation in the case of
> Prob (i.e. markup); now I am investigating vertical space estimation for the
> case of Grob (i.e. score). The problem is that when the user tries to fit
> more systems on the page by decreasing the spacing/padding, the final page
> layout does take it into account, but it has no effect on the estimations at
> the page-breaking stage. The visual result is that the lines do get closer
> together, but the number of lines per page still remains the same, leaving a
> big empty gap at the bottom of the page.
>
> This problem is caused by the calculation of ext_len in the "for (i=...)"
> cycle in Page_breaking::min_page_count().
> For illustration, I have attached two examples: simple-nolyrics.ly, and the
> same score with added lyrics, simple-lyrics.ly. When there are no lyrics,
> the estimation works as expected. The ext_len in this case is 7.947, and the
> specified padding of 1.2 causes the systems to be nicely squeezed together.
> Now if we add lyrics, the final spacing and the estimation start to diverge
> dramatically. In the final layout of the page, the lyrics do not cause a
> significant change to the distance between the systems: the lyrics just sit
> in the gap which was already there. But the estimator, during the page
> breaking, get confused: for each line, the rod is lengthened by ext_len
> padding, and ext_len in this case is as much as 10.203. So the page breaker
> thinks that the systems are much taller than they will finally prove to be
> when the final spacing is done.
The estimated height for the whole system _should_ take into account the
fact that the lyrics can be squeezed between the systems. Have a look at
the comment in align-interface.cc:104 (which should get called as a
result of sys->pure_height()). The begin_of_line_extent should be zero
for lyrics, which should allow the lines to be close together in the
height-estimation procedure.
> Trying to do something about this ext_len problem, I traced the origin of
> the ext-len back to the Y-ext of the Grob (fill_line_details() calls
> sys->pure_height(), which calls get_property_data("Y-extent")). Bien sûr,
> the Y-extent includes the whole height of the lyrics.
>
> I am not sure what can be done to reconcile the estimator with the actual
> spacing, so that users can get tight spacing. My understanding is that the
> final spacing actually tries to avoid skyline collisions; the page breaker
> ignores the actual shape of the skyline and treats the systems as solid
> rectangular blocks. So the only possible workarond would be to manually
> indicate the ext_len to the page breaker (something like, a block variable in
> the score layout) -- extremely ugly, and I would only opt for that if I knew
> for sure that all other options were exhausted.
There is a workaround, but it's hacky: do something like
\paper {
page-breaking-between-system-spacing #'padding = #'-5.0
}
The page-breaking-between-system-spacing variable was added exactly for
this situation, so that you can override the page breaker's estimations
in case they're off. But you only get to plug in a single value for the
whole \book.
Cheers,
Joe
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Lyrics break estimation of vertical spacing
Here are the two illustrative examples.
On Fri, 19 Mar 2010 11:05:30 -0400, Boris Shingarov wrote:
On Wed, 13 Jan 2010 19:37:14 1100, Joe Neeman wrote:
>
> > It's nice to see someone else touching the page-breaking code
>
> The more I dig into it, the more questions I have.
> Back in January, we talked about vertical space estimation in the
case of Prob (i.e. markup); now I am investigating vertical space
estimation for the case of Grob (i.e. score). The problem is that
when the user tries to fit more systems on the page by decreasing the
spacing/padding, the final page layout does take it into account, but
it has no effect on the estimations at the page-breaking stage. The
visual result is that the lines do get closer together, but the number
of lines per page still remains the same, leaving a big empty gap at
the bottom of the page.
>
> This problem is caused by the calculation of ext_len in the "for
(i=...)" cycle in Page_breaking::min_page_count().
> For illustration, I have attached two examples:
simple-nolyrics.ly, and the same score with added lyrics,
simple-lyrics.ly. When there are no lyrics, the estimation works as
expected. The ext_len in this case is 7.947, and the specified
padding of 1.2 causes the systems to be nicely squeezed together. Now
if we add lyrics, the final spacing and the estimation start to diverge
dramatically. In the final layout of the page, the lyrics do not
cause a significant change to the distance between the systems: the
lyrics just sit in the gap which was already there. But the
estimator, during the page breaking, get confused: for each line, the
rod is lengthened by ext_len padding, and ext_len in this case is as
much as 10.203. So the page breaker thinks that the systems are much
taller than they will finally prove to be when the final spacing is
done.
>
> Trying to do something about this ext_len problem, I traced the
origin of the ext-len back to the Y-ext of the Grob
(fill_line_details() calls sys->pure_height(), which calls
get_property_data("Y-extent")). Bien sûr, the Y-extent includes the
whole height of the lyrics.
>
> I am not sure what can be done to reconcile the estimator with the
actual spacing, so that users can get tight spacing. My understanding
is that the final spacing actually tries to avoid skyline collisions;
the page breaker ignores the actual shape of the skyline and treats the
systems as solid rectangular blocks. So the only possible workarond
would be to manually indicate the ext_len to the page breaker
(something like, a block variable in the score layout) -- extremely
ugly, and I would only opt for that if I knew for sure that all other
options were exhausted.
>
> Boris
>
>
>
>
>
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> http://lists.gnu.org/mailman/listinfo/bug-lilypond
>
>
\version "2.12.2"
\paper {
#(set-paper-size "b5")
indent = 0.0
tagline = ##f
between-system-spacing = #'((space . 1.20) (padding . 1.20) (minimum-distance . 1.20))
ragged-bottom=##t
ragged-last-bottom=##t
%min-systems-per-page=12
}
\book {
\score {
<<
\new Voice = "cantus" {
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
}
>>
} %score
} %book
\version "2.12.2"
\paper {
#(set-paper-size "b5")
indent = 0.0
tagline = ##f
between-system-spacing = #'((space . 1.20) (padding . 1.20) (minimum-distance . 1.20))
ragged-bottom=##t
ragged-last-bottom=##t
%min-systems-per-page=12
}
\book {
\score {
<<
\new Voice = "cantus" {
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g' f' g' a' b' a' b'
f' g
