[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