On Sun, 2006-10-01 at 11:17 +0200, Nicolas Sceaux wrote: > Joe Neeman <[EMAIL PROTECTED]> writes: > > > Just some random thoughts: it seems that you need the exact extent and > > staff-extent for determining if a system is stretchable. If it were > > possible to do it another way (say by setting a property from the C++ > > side whenever we see a VerticalAlignment with more than one child) then > > you could theoretically do everything using just the estimated extents. > > > > That is, you could calculate the maximum stretch before the systems have > > even been typeset and insert the tweaks immediately instead of writing > > them to a file. That way, "two-pass" spacing happens automatically on > > only one pass. Of course, it would be less accurate since you rely on > > the estimated extents, but it's something to consider anyway. > > Very interesting! Doing the system stretch in a single pass would be > really cool. I didn't know there was such a thing like an estimated > extent. Might you point me to the part of the code where this may be > done?
The estimated Y-extent is done in the C++ code in order to find a good page breaking before actually typesetting the systems. It's currently available as the 'Y-extent-estimate property of the lines. Of course that's not very useful since scheme doesn't get to see the lines until they're already typeset, by which point it's too late. I can think of two options at this point. One would be to just do the stretching in C++, since the data's already there. Another would be to generate some "fake" lines (for example, probs with no properties except for 'Y-extent-estimate and maybe 'is-stretchable). Then you do the stretching in a similar way to the current method and set the results as another property of the probs. C++ gets the probs back and sets the correct grob properties before typesetting the systems. The second is a bit more convoluted but it has the advantage that you can probably reuse most of the existing stretching code. > If there is no objection, I'll commit the two pass stuff anyway, as it > will eventually used by a few people (that is, at least two :). > But then working on the one pass spacing would be something valuable. Absolutely. I think the one-pass spacing is something that needs a non-trivial amount of work and it can wait until after 2.10. _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel