Re: Getting the height of a system.

[Joe Neeman]

On Mon, 2006-05-22 at 10:57 +0200, Han-Wen Nienhuys wrote:
> Joe Neeman schreef:
> >> In that case, you could get the approximate height of one broken system 
> >> in logarithmic time.
> >>
> > Here's a first attempt at doing this. It isn't complete or well-tested
> > yet. I add 4 grob properties
>  >
> > Y-extent-safe
> > Y-offset-safe
> > default-Y-extent-is-safe
> > default-Y-offset-is-safe
> > 
> > where Y-extent-safe and Y-offset-safe are functions that take 3
> > arguments, a grob, and the starting and ending column ranks.
> > default-Y-blah-is-safe just marks grobs where we don't need a
> > Y-blah-safe because the default Y-blah doesn't introduce side effects.
> > This is pretty much just there for NoteHead.
> 
> Can't we just get away with assuming that functions that don't have 
> y-extent-safe have point dimensions?
I think so, but we would still need to have a guess for Y-offset to make
use of this.

> BTW, naming would be
> like
> 
>    safe-foo-bar
> 
> "safe" might even be renamed "pure" or "readonly" which better reflects 
> the idea of the functionality.
OK.

> 
> > I've implemented Y-extent-safe for axis-group-interface,
> > hara-kiri-group-interface and NoteHead. I think it might be useful to do
> > side-position-interface also since that will take care of markups,
> > rehearsal marks and some other things that tend to be positioned away
> > from the staff. But that looks a bit harder so I haven't done it yet.
> > 
> > Is this similar to what you had in mind?
> 
> Actually, no.
> 
> What I had in mind was only to detect when hara kiri staves are alive or 
> not, and use that to make an estimate of system height (with a fixed 
> system height setting). Your approach here will get more accurate 
> results, but I'm a little worried that the XXX_safe functions and 
> properties will spread throughout the code, which is a problem as 
> they're duplicating functionality.
Yes, but I think 99% of the duplicated functionality is already in my
patch. Everything else I can think of, could be refactored like I've
done to Align_interface::align_elements_to_extents.

Most of the side-effect-causing stuff in the vertical spacing code comes
from calling extent and relative_position. Since I already have pure
versions of those, it should just be a matter of adding (bool pure, int
start, int end) to the paramaters of a few more functions and using
Grob::safe_height instead of Grob::extent when pure is true.

> 
> Does this patch already work for determining system heights, or is just 
> the beginning of the work? How much more must done?
It works, but it currently only measures the height of StaffSymbol and
NoteHead. I'd like to expand it to also count things that are typically
above and below the staff. side-position-interface and
self-alignment-interface would probably be the only things left to do.
Maybe an estimate for Stem too, but that shouldn't be very important.

I want to be a little more accurate than using a fixed position for each
staff because the height of a staff can vary from piece to piece. For
example, I have a string quartet in which the 1st violin part has
systems about 20% taller than the 2nd violin because it tends to have
higher notes. The consequence in the page-breaking algorithm for
underestimating all the staff heights is that it will put too many
systems on a page and the systems will run off the bottom of the page.

OK, so the fix is easy for the user (just put system-height =
something-bigger) but I think the probability of obvious mistakes in the
default output should be _very_ low or else (1) it's inconvenient for
the user and (2) we'll get millions of duplicate bug reports and Mats
will have to patiently answer them all :)

> 
> BTW, the idea of precomputing when parts of a VerticalAlignment are 
> hara-kiri'd can still be used to speed up the end result, I think.
Yes, I'll do that.