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

[address@hidden]

On 26 janv. 2013, at 23:21, address@hidden wrote:

> This would take me a couple more hours to figure out.  Do I want to ?
> 
> It seems the "caching" is not the type that saves us from
> re-computation.  It simply stores the skylines Scheme objects.
> 

Yup.

> 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.
> 
> Sometime before printing, I assume you want the positioning information
> to be updated in the grob.  When do you propose to do so ?   How will
> storing the outline of the staff without the hairpin in
> 'inside-staff-skylines' help ?

The broad goal is:

1) Cache interior skylines.
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.  This, in turn, means that a pure version of this 
Y-offset can be cached, cleared, and refined over time.
3) Use these pure properties way farther downstream.  So, for example, if any 
object's Y-position depends on the Y-position of a cross-staff grob, only 
calculate it's pure height for vertical spacing calculations.  Note that, for a 
system without cross-staff grobs, pure-Y-offset and Y-offset would be 
equivalent.
4) Do skyline spacing in the page breaker and Page_layout_problem with pure 
heights instead of heights.
5) Trigger the calculation of real heights for cross-staff-grobs (and the 
offset for grobs that do side-positioning) after Page_layout_problem::solve 
spaces stuff.

Bottom line: currently, pure heights are used to make good guesses for 
horizontal spacing, and then once the spacing is chosen, real heights are used. 
 What I want is for pure heights to be used for horizontal spacing, then 
cleared from the cache and recomputed for vertical spacing, then use real 
heights for final vertical layout.

Stuff like your cross-staff-grob-full piano piece would benefit a lot from this.

> 
> You can post a commit series to Reitveld if you like.  On the branch
> with the final commit, just checkout the first commit, `git-cl upload
> master`, checkout the next commit...
> 
> 
> https://codereview.appspot.com/7185044/diff/4001/scm/define-grob-properties.scm
> File scm/define-grob-properties.scm (right):
> 
> https://codereview.appspot.com/7185044/diff/4001/scm/define-grob-properties.scm#newcode1115
> scm/define-grob-properties.scm:1115: grobs that are elements of an axis
> group that do not have an
> "elements of a @code{VerticalAxisGroup} and that do not"
> 
> https://codereview.appspot.com/7185044/diff/4001/scm/define-grob-properties.scm#newcode1117
> scm/define-grob-properties.scm:1117: or other vertical axis like lyrics,
> dynamics, etc..")
> "or other @code{VerticalAxisGroup}s like @code{Lyrics}, @code{Dynamics}"
> because dynamics like \p \< \f typically do have outside-staff-priority.
> 

Maybe it's not worth it to do all this intermediate stuff...you're right that 
it takes time for others to understand (and even for me to understand) as I'm 
working towards this goal.  The project is even more ambitious as the last 
skyline one in terms of the amount of code that will be touched, so it may be 
difficult for people to understand the utility of things until I have a final 
working vertical spacing version of LilyPond.  The only problem is that there 
will be a branch that is significantly different from staging that I won't be 
able to refactor into separate commits without a heapload of work.  But it will 
avoid people unnecessary review of intermediary steps.