Re: proposed enhancement to vertical stretching logic

[Joe Neeman]

On 7/1/08, Reinhold Kainhofer <address@hidden> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> - -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am Mittwoch, 25. Juni 2008 schrieb Joe Neeman:
>> However, I think that LilyPond´s spring algorithms
>> are already close to the ones you are describing. Have a look in
>> simple-spacer.cc -- it is reasonably self-contained. Unfortunately, these
>> spring algorithms aren´t used in the vertical stretching step, which is
>> completely naive; they are only used in horizontal and vertical spacing
>> (ie. between systems, not within them).
>
> I've now had a quick look and think that the springs-and-rods problem solver
> needs to be inserted in Align_interface::align_elements_to_extents.

Actually, I think that it would be better to unify the stretching with
the system placement that is currently done in layout-page-layout.scm.
That is, I think that we should space the whole page as one big
rod-and-spring problem. This would require some significant surgery,
but I think it is the right approach.

> Unfortunately, I'm seeing several problems formulating the springs-and-rods
> problem:
>
> 1) Each vertical object (staff, lyrics, figured bass) has an entry in the
> elements, some with stretchable=#f, others with #t. See the attached file
> (on
> the second page I copied that information; The vertical axis groups with
> stretchable=#f are apparently the lyrics, while the others are staves). PDF
> is
> at:
> http://www.fam.tuwien.ac.at/~reinhold/temp/equal_spacing.pdf
> While this makes sense in general, for stretching we need to use springs
> that
> go from one staff to the next, even if lyrics are in between. Unfortunately,
> I don't know how to detect which of the elements are lyrics and should be
> disregarded for stretching (or at least the stretching should not happen
> only
> between lyrics and next staff; lyrics might induce spacing that is a little
> larger than without lyrics, but in general not influence the stretching
> much).

I'd suggest introducing a new property in VerticalAxisGroup and
setting appropriate defaults in the Lyrics context (and maybe in other
contexts). This is the way keep-fixed-while-stretching is done.

> 2) To work properly also with rhythmic staves and tab staves, I think that
> the
> springs should go only from the end of one staff to the beginning of the
> next, as otherwise the staff extends will already take away some of the
> vertical space that should be equally distributed. How do I get the staff
> extents?

I guess you need to find the StaffSymbol somehow...
By the way, in simple-spacer.cc, two springs can only meet at a point
(ie. you never get rods with no parallel springs). But its possible to
get the same effect by tweaking the spring constant and ideal length
of a spring.

> 3) How do I get the skyline of a staff (or rather, the minimal distance
> between two staves, which is calculated from overlaying the two skylines) to
> use as the rod length?

Using get_skylines in align-interface.cc (if you need to use this
function elsewhere, feel free to make it a public member of
Align_interface).

> 4) How do I move the staves/lyrics/figuredbass/etc. to the correct vertical
> position? AFAICS, there is only Grob::translate_axis, which moves the object
> by a certain amount, but does not allow setting a certain position...

I suppose you could always add such a function to Grob, but you can also do
g->translate_axis(pos - g->relative_position(common, Y_AXIS), Y_AXIS).
Anyway, you should always be careful about moving things to a
particular position, because all positions are relative. This is why
translate_axis is probably better.

Hope that helps,
Joe