Skylines and certain grob properties (rotation, extra-offset)

[Torsten Hämmerle]

Hello developers,

When dealing with skylines in  issue #5307 "Skyline Refinements (Rounded
Boxes and Rotated Ellipses)"
<https://sourceforge.net/p/testlilyissues/issues/5307/>  , I noticed that
the rotation grob property is not reflected in the skylines at all.
At present, skylines do not know about grob properties as rotation, because
skylines are built before these grob properties are finally applied to the
stencil.

How to deal with grob properties rotation and extra-offset in skylines?


If we take a look at an example from a snippet demonstrating how to rotate a
crescendo Hairpin, we can clearly see that the Hairpin's skyline is totally
ignorant of the rotation set by
\override Hairpin.rotation = #'(20 -1 0)

<http://lilypond.1069038.n5.nabble.com/file/t3887/skylines-rotation-grob-property-01.png>
 

As a (wanted?) side-effect, the resulting Hairpin ignores paddings so that
it even protrudes into the stave.

If we add a second stave, the skyline prevents the staves of moving closer
together, because vertical spacing does not know the Hairpin has been
rotated (and thus moved out of the way) at all:

<http://lilypond.1069038.n5.nabble.com/file/t3887/skylines-rotation-grob-property-02.png>
 

The result is a bad vertical spacing.

If we build the skylines from the rotated stencil instead (by appyling
rotate_degrees if the rotation property of the grob has been set), the
skylines will represent the final (rotated) stencil:

<http://lilypond.1069038.n5.nabble.com/file/t3887/skylines-rotation-grob-property-03.png>
  

When making the skyline take care of grob rotation, the resulting Hairpin
positioning will respect paddings by keeping its distance to the stave and
other objects, so that the Hairpin positioning will be affected by this
change.
When applying an extra-offset to move it further up, this will (again) not
be reflected by the skyline and, consequently, vertical spacing will not
automatically take advantage.

<http://lilypond.1069038.n5.nabble.com/file/t3887/skylines-rotation-grob-property-04.png>
 
Making the skyline consider the extra-offset, however, would prevent the
grob from overlapping other grobs and thus extra-offset would not have any
effect anymore.

In this case, the cat bites its own tail, as we say in German.
On the one hand, a skyline ignoring the extra-offset prevents the lower
stave from getting closer, on the other hand, a skyline sticking to its grob
prevents the Hairpin from being moved up by extra-offset because padding and
the presence of the stave will keep it down.

But even with the (rotated) skyline in place, the result is still much
better than in the current LilyPond version, IMHO.

Question: Should skylines reflect the grob properties rotation and
extra-offset?

As the one and only purpose of skylines is to optimize spacing, I think they
should match the actual grob placement as closely as possible.

What do you think about making skylines consider the grob properties
rotation and extra-offset?

(1) keep everything as it is
(2) skylines should reflect both grob rotation and grob extra-offset
(3) skylines should reflect grob rotation only
(4) skylines should reflect grob extra-offset only

Obviously, (1) is sub-optimal and (2) and (4) would make extra-offset
useless in many standard cases because it has been designed for arbitrary
shifting around and shouldn't be hampered by skylines and it should be
possible to make grobs overlap by using extra-offset.

But skylines taking grob rotation into account would be a good idea,
wouldn't it?


Thanks
Torsten



--
Sent from: http://lilypond.1069038.n5.nabble.com/Dev-f88644.html