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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel