lilypond-devel
[Top][All Lists]
Advanced

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

Re: two pass spacing patch


From: Joe Neeman
Subject: Re: two pass spacing patch
Date: Sun, 01 Oct 2006 20:25:43 +1000

On Sun, 2006-10-01 at 11:17 +0200, Nicolas Sceaux wrote:
> Joe Neeman <address@hidden> 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.




reply via email to

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