David Kastrup <dak <at> gnu.org> writes: > Ignored or not: those are values indicating breakpoints of the current > system. They should not even be available for functions evaluated > before any line-breaking. Or maybe they are called for one of a set of > tentative not-final line breaks, but in that case it would make little > sense to call the post-linebreak (impure?) functions without the actual > linebreak information. >
Yes. The parameters 'start' and 'end' let the page-breaking code estimate how tall each system will be by calling the pure-height function on each VerticalAxisGroup, which might call pure-height on its contained spanners like Slurs, whose height could depend on where the line-breaks are. The results are cached in a hash table indexed by the start/end pair. The idea was to consider line-breaks and page breaks simultaneously, to find the best overall page layout. In practice, this does not work very well because 1) there is no time to do a trial horizontal spacing for each line-break set, so the page fit is evaluated with conservatively estimated heights of systems only, not skyline 2) in frenched scores, where well-chosen line-breaks let us remove more empty staves, the page-fit score often favors generating mostly-empty staves to fill pages more uniformly. We can't simply remove the simultaneous consideration of line- and page-breaks, because page-turn-breaking needs to put the final line- break on each odd page at a feasible point. We might be able to shift to two strategies: 1) line-breaking then best-fit onto pages using the skylines of the lines, 2) page-turn-breaking at feasible places, then line breaking within each page. The usual (not 'pure') functions to determine Y-offsets are free to look up properties of other objects, that can call functions to look up the line-breaking results or induce line-breaking if it hasn't been done yet. The 'pure' functions are supposed to avoid calling functions with the side effect of inducing line-breaking, and that has caused a proliferation of 'pure' versions of functions where we would not expect a distinction between pre-/post line-breaking _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
