"Phil Holmes" <[email protected]> writes: > ----- Original Message ----- > From: "David Kastrup" <[email protected]> > To: "Werner LEMBERG" <[email protected]> > Cc: <[email protected]> > Sent: Monday, July 25, 2016 2:07 PM > Subject: Re: vertical movement without anchors > > >> Werner LEMBERG <[email protected]> writes: >> >>>>> When has this changed? Or maybe there are still situations where an >>>>> anchor is needed, thus the example has to be improved? >>>> >>>> The respective diff from 2.16 to 2.18 in scm/define-grobs.scm reads: >>>> [...] >>>> >>>> However, reverting all that does not appear to make a change (unless >>>> I am doing something wrong here). So I'm not sure what to attribute >>>> the change to (the logs for lily/text-engraver.cc or >>>> lily/script-engraver.cc do not show anything suspicious to me >>>> either). >>> >>> Thanks for testing. >>> >>>> How important is it to figure out the responsible change? >>> >>> Well, it's not important (at least not for me), but `anchors' was a >>> central concept in vertical positioning of grobs, and lo and behold, >>> it is no longer necessary, so we can correct the documentation. >> >> Could have something to do with issue 3330, committed as part of >> 2.17.19. No idea just _what_, though (but it streamlines and amends the >> spacing engine considerably, so it would be a likely candidate). Do we >> have the docs for 2.17.18 and 2.17.19 for comparison? In other words, >> I'm a bit lazy. >> >> -- >> David Kastrup > > Happened between 2.17.26 and 2.17.28
Ok... I suspect commit 2c0f56cc2c2b7e6d3a5f7792c006e55675c9e0d7 Author: Keith OHara <[email protected]> Date: Sun Dec 23 13:13:44 2012 -0800 Measure 'staff-padding' to reference points; issue 3026 Reverting its C++ part (the merge conflict in the Scheme part in scm/define-grobs.scm would be rather messy to clean up) in lily/side-position-interface.cc (and a followup commit for issue 3626 removing a then-unused variable) results in output corresponding to the old situation. And the issue description very much matches the symptoms. The salient difference in the NR example is that the \null addition changes the bounding box (to include (0,0), the reference point) but not the reference point, and Keith's commit causes the padding to be measured to the (unchanged) reference point rather than the (changed) bounding box. So this does not really have anything to do with "anchoring markups" as far as I can see. Unless you consider a markup "anchored" when its bounding box and/or skyline includes the reference point. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
