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.
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 ?
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.
https://codereview.appspot.com/7185044/
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
