On 2012/12/22 06:50:46, mike7 wrote:
It is cyclical for cross staff grobs in general. As staves spread
apart
vertically, cross-staff grobs' shapes change, which changes potential positioning of grobs above/below them, which changes staff spacing,
which
changes the shape of cross staff grobs, which...
But just to be clear, this is happening in your head only; LilyPond has been ignoring graphical-objects marked 'cross-staff' for purposes of vertical spacing. Generally, the layout is conceptually a large dependency tree (a directed graph) with each piece of positioning data a separate node. Several situations (issue 2589 for example) would give a cycle in that graph. Whenever LilyPond evaluates a piece of positioning data that is associated with a grob property that references a Scheme procedure, she sets a flag to break any cycle if the evaluation of the procedure tries references the positioning data being calculated. In some cases cycles are broken by using tentative positioning data instead of the real data. The node is split, with one version being called 'pure' (misleadingly hinting at an analogy to "pure functions") which means roughly that the 'pure' positioning data depends on a limited set of other nodes. Sometimes we can divide the layout into stages, where some types of data depend on a small set of decisions, that depend in turn on a disjoint set of data. At line breaking, for example, all minimum horizontal distances between columns are determined, but no stretching of lines has been done thus no slur shapes have been set. Nowhere that I have seen are there iterations to converge on a solution. Instead, systems are set up that can be solved, such as the rods-and-springs system used for both note-spacing and vertical layout. https://codereview.appspot.com/6827072/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
