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

[address@hidden]

On 22 déc. 2012, at 08:40, address@hidden wrote:

> 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;

cross-staff grobs are not the only thing about which one could say to me "that 
is happening in your head only"...

> LilyPond has
> been ignoring graphical-objects marked 'cross-staff' for purposes of
> vertical spacing.

True.

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

True.

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

True.

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

True.

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

True.

> 
> Nowhere that I have seen are there iterations to converge on a solution.

There are several loops in LilyPond that iterate while dirty and converge to a 
solution for limited spacing problems (beams and fingering come to mind).

I'd like for this to be the case for vertical spacing.  Or at least for certain 
pure estimations to be periodically updated so that the spacing algorithm, 
during its one pass, uses the most accurate data available.

>  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/