Re: Getting the height of a system.

[Han-Wen Nienhuys]

Joe Neeman schreef:
> I think this could be even more expensive because my page breaker looks at a 
> _lot_ of different line breaking configurations. On the score I have been 
> using for coverage tests (Haydn op 76, no 3, 1st violin part), the page 
> breaker tests more than 4000 different line breaking configurations so this 
> is already much more expensive than doing it for 50-60 copies of the score.

ok

> > Also, it's not completely possible to compute the height of an isolated
> > system: some grobs (notably spanners like slur) look at the next system
> > to decide how to format across line breaks.
>
> Would it be acceptable to skip those cases? This would be a good point to 

Yes.

> mention that I don't really need the exact height of the system -- just an 
> approximation. The current approximation I am using (setting a score-wide 
> system-height) is _very_ crude but it works pretty well as long as there are 
> no RemoveEmptyStaffContexts or very high notes.

I think that actually the RemoveEmptyStaffContexts are the difficult 
parts, the high notes would be an exception.


> > Secondly, although it will be nicely portable, it also sounds like a lot
> > of work. Isn't it a lot easier to simply do a fork() and let the OS
> > clean up after us? Perhaps if the vertical spacing is completely
> > working, we can consider doing the full-blown copy and restore. Also,
> > for large scores, fork() is an interesting option, as we could get some
> > benefit from using SMP.
>
> But then the OS would have to deal with copying the data and it can only do 
> that in page-sized chunks. So wouldn't this just increase the amount of stuff 
> that gets copied?

Yes, but it's a much easier to be certain that it is correct than 
writing copying and cleanup stuff in C++.

> There is actually another possibility that I've only just thought of so it's 
> pretty half-baked:
> Add an approximate-Y-extent to each grob that
> 1) leaves the grob constant (in particular no caching)
> 2) ignores anything in the object_alist_ that doesn't have a system.
>
> Then we could even get away with not doing any break-substitutions (until it's 
> time to typeset things, of course) with something like:
> Real System::guess_line_height (Column_x_positions col)
> {
>         set_bound (LEFT, col.cols_[0]);
>         set_bound (RIGHT, col.cols_.back ());
>         for (vsize i = 0; i < col.cols_.size (); i++)
>         {
>                 // translate axis (as in System::break_into_pieces)
>                 col.cols_[i].system_ = this;
>         }
>         set_loose_columns (this, &col);
>         SCM h = this->get_property ("approximate-Y-extent");
>         for (vsize i = 0; i < col.cols_.size (); i++)
>         {
>                 // translate the axis back
>                 col.cols_.system_ = 0;
>         }
>         return scm_to_double (h);
> }
>
> That is, we can pretend we're working on the original system and get away with 
> it because approximate-Y-extent will be guaranteed not to leave any 
> side-effects. Condition (2) means that we can get away with doing it a system 
> at a time. A spanner that crosses a line break will realise that it is 
> crossing the line break and will try to provide a sensible guess.

I think that's a sensible stop gap solution, but I have a feeling it 
will be a lot of work. Perhaps it's better to approach from the other 
side, and only explicitly do this for alignment spanners.

Perhaps you could even compute for each VerticalAxisGroup the range of 
column ranks where it would disappear, and use that information add a 
method to compute the approximate height of an alignment spanner, where 
you explicitly call it with a (begin,end) pair of column ranks.

In that case, you could get the approximate height of one broken system 
in logarithmic time.

--

Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen

LilyPond Software Design
 -- Code for Music Notation
http://www.lilypond-design.com