[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Getting the height of a system.

From: Han-Wen Nienhuys
Subject: Re: Getting the height of a system.
Date: Mon, 15 May 2006 12:20:07 +0200
User-agent: Thunderbird 1.5 (X11/20060313)

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.


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


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 -

LilyPond Software Design
 -- Code for Music Notation

reply via email to

[Prev in Thread] Current Thread [Next in Thread]