http://codereview.appspot.com/342060043
As has been agreed in thread http://lilypond.1069038.n5.nabble.com/Skylines-and-certain-grob-properties-rotation-extra-offset-tt212002.html, skylines should reflect the grobs' "rotation" property.
The "rotation" property (grob-interface) will be applied to the stencil after skylines have been built. Therefore, the skylines currently do not know about grob rotation and stoically stay in place.
In the example PNG file, you can see the original skylines on the left compared to the enhanced skylines on the right:
All the best,
Torsten
issue 5319: Make skylines reflect grob rotation
modified: ../lily/include/stencil.hh
Add parameter to skylines_from_stencil for rot (in analogy to pad)
modified: ../lily/stencil-integral.cc
Stencil::skylines_from_stencil
If new rotation parameter rot is specified, use a rotated copy of
the original stencil to build the skyline transformation matrix.
As the rotation is rarely used, the general (non-rotated) case will
still use the original stencil as before.
Grob::vertical_sklyines_from_grob and Grob::horizontal_skylines_from_grob
Read "rotation" property an pass it (SCM) to skylines_from_stencil.
modified: ../lily/accidental.cc
Accidental_interface::horizontal_skylines
Read "rotation" property and pass it (SCM) to skylines_from_stencil.
Announced in ../Documentation/changes.tely
Documentation example slightly adapted (20° to 15°) to new skyline
behaviour (padding will now be respected). In all affected languages:
modified: ../Documentation/de/notation/changing-defaults.itely
modified: ../Documentation/es/notation/changing-defaults.itely
modified: ../Documentation/fr/notation/changing-defaults.itely
modified: ../Documentation/it/notation/changing-defaults.itely
modified: ../Documentation/ja/notation/changing-defaults.itely
modified: ../Documentation/notation/changing-defaults.itely
modified: ../input/regression/skyline-color-rotation.ly
(20° to 15°, cf. documentation)
new: ../input/regression/skyline-grob-rotation.ly
New regression test.
issue 5312: Key cancellation glyph position inconsistent
file lily/key-signature-interface.cc
Now using two intervals representing the "vertical skylines" of two
adjacent natural glyphs. This makes a better model of the actual glyph
shape than the original single point within an inverval.
Now we can distiguish between all three cases:
(1) no overlap -> no additional kerning needed
(2) just touching (overlap, but intesection length 0) -> kerning 0.15
(3) overlapping -> kerning 0.3
Case (2) is the new one that couldn't be handled before:
Just touching at the corners made the glyphs cling together.
Using same interval technique as before, but I renamed the Slices from
pos and overlap_pos to
ht_right and last_ht_left.
Using quarter stave-spaces as to get a better (integer) resolution.
http://codereview.appspot.com/342060043
Diff:
New upload due to inconsistency
http://codereview.appspot.com/342060043
Passes make, make check and a full make doc.
Patch on countdown for May 10th.
Patch counted down - please push.
Patch against curren master attached.
Please push it for me.
Thanks,
Torsten
Thank you Torsten,
Thank you James,
Has there been a paradigm shift or is the "Fixed_2_20_0" label just an unintended by-product of the current stable release discussion?
Cheerio,
Torsten
"Torsten Hämmerle" be-3@users.sourceforge.net writes:
Just a confusion I'd say. Definitely not going to be in 2.20.
--
David Kastrup
OK, thanks, fair enough, that's why it asked.
Set to "Fixed_2_21_0".