Re: Uses single algorithm for side-position spacing. (issue 6827072)

[k-ohara5a5a]

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/