lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pure/impure?!?!


From: Keith OHara
Subject: Re: pure/impure?!?!
Date: Sat, 23 May 2015 23:12:37 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]