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

[Keith OHara]

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.

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.)

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.

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.


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.