Re: Caches the interior skylines of vertical axis groups and systems. (issue 7185044)

[mike]

On 28 janv. 2013, at 06:33, Keith OHara <address@hidden> wrote:

> On Sun, 27 Jan 2013 01:45:16 -0800, address@hidden <address@hidden> wrote:
> 
>> On 26 janv. 2013, at 23:21, address@hidden wrote:
>> 
>>> The tracker says the overall goal is to remove a call to the function
>>> translate_axis.  In the example
>>> { g4\> g'_"pico"  g' g\! }
>>> when we decide to move the "pico" between hairpin and staff, the call to
>>> translate_axis records the new position in the TextScript grob itself.
> 
>> The broad goal is:
> [...]
>> 2) Move outside-staff-priority purely to the side-position interface.  
>> Objects with lower outside-staff-priorities (+ the interior skylines of 
>> vertical axis groups) become support objects for those with higher.  This 
>> means that all positioning information is calculatable via a Y-offset 
>> callback, so no more need for translate_axis.
> 
> So in the example
> { g4\> g'_"pico"  g' g\! }
> the text "pico" has its Y position referenced to the staff, its Y-parent.
> 
> Currently, the TextScript holding "pico" has a Y-offset property that is a 
> function computing the position to clear everything on the staff.  (Y-offset 
> considers the parent-child relationship only.)  The results of the function 
> pointed to by Y-offset are stored in the C++ data-structure representing this 
> TextScript.
> 
> Currently, the TextScript and Hairpin, both having the staff as Y-parent, are 
> then arranged relative to each other.  Any shifts required by this arranging 
> are applied, by translate_axis(), to the stored positions in the Hairpin and 
> TextScript.
> 

Yup.

> You propose (I think) to avoid collisions between Hairpin and TextScript 
> directly in the functions used to compute Y-offset.  Hairpins are placed 
> first, then TextScripts, so in this case the TextScript gets a pointer to the 
> Hairpin added to its list of side-support-elements.  We would need to walk 
> through outside-staff priorities and put these pointers in place *before* 
> computing Y-offsets, opposite to the current order of opertions, so that the 
> TextScript's Y-offset computation has the information to see and avoid the 
> Hairpin.  (Now I have a guess why you might want the skylines outlining the 
> staff and outlining Hairpin to be "cached" in Scheme objects.)

Yup, except that in the new patch I proposed, instead of adding it to this 
list, I use the vertical-skyline-elements array of the vertical axis group to 
which the grob belongs.  That is because outside-staff-placement is 
conceptually different from normal side placement, as outside-staff objects can 
slide under other outside-staff objects whereas we don't want this for normal 
side placement.

> 
> This would change Y-offset to be the position relative to parent, from all 
> causes, rather than just the offset *due* to the parent.  Some care would be 
> required to avoid circular dependencies, but it should be possible because 
> the data dependencies are already there in the current method.

Everything should be fine in the patchset I just uploaded.

> 
> The change to remove the call to translate_axis() in 
> axis-group-interface.cc::avoid_outside_staff_collisions(), plus whatever 
> preparation is necessary for that change, would be conceptually easier to 
> review all at once.

Done.

> 
> I have a glimmer understading of your plan for cross-staff items.  If the 
> Hairpin in the example was instead a cross-staff Slur, I see that you hope to 
> (re)-position the "pico" by computing the Y-offset, which will use whatever 
> position information is available at the time.  It seems you would need two 
> passes of positioning "pico": one to compute staff skylines (conservatively) 
> so LilyPond can space the staves, and then one to position the "pico" around 
> the slur.  It do not yet have more than glimmer of hope that it will actually 
> be possible.
> 

I have a conceptual roadmap in my head and, so far, the elimination of the 
translate_axis call proposed in the most recent patchset has gone OK (it passes 
regtests).  Now, we just need to implement better pure skylines, use them for 
vertical axis group spacing with the most robust information possible (i.e. 
real beam placement can be used after X positioning is done - no need to be 
pure), and then we should be set...

Cheers,
MS