On Oct 1, 2007, at 21:50, Simon Pepping wrote:
<snip />
[Me:]
I wouldn't think so. Total-fit for me precisely implies taking
into account
the fact that the available IPD may alter from one page to another.
What FOP Trunk currently does in that scenario is definitely not a
total-fit, or
at least, only in the case the available IPD does not change
between pages.
The key to that is the fact that FlowLM.getNextKnuthElements()
gets called
only once per fo:flow, and in the base-loop passes on a
LayoutContext to
its descendants with the IPD of the first page in the page-
sequence. This
IPD (or a portion thereof) is ultimately used by *all* descendant
LineLayoutManagers...
I definitely disagree with you. As we have it now, the total-fit
algorithm needs to have all lines of the page sequence before it can
calculate the best page breaks. Therefore all paragraphs must be
broken into lines before page breaking starts. There is no room for
changing the page widths.
The total-fit algorithm has no point where you can interfere. You need
to give it all information at the start.
That is not DISagreeing with me, I think (almost on the contrary). I
did not mean total-fit in the sense of the implementation of the
algorithm, but total-fit as to the end-result: as such, a total-fit
result may precisely require a breaking-up into many smaller best-
fits. A total-fit result may just be much more difficult to
accomplish with a total-fit algorithm, than by a succession of best-
fit loops, interrupted and resumed at regular intervals.
What I meant was (in reply to Chris' question):
If the layout-master-set is such that the region-body width changes
from one page to the next, I would not expect end-users to
additionally have to fiddle with extension-properties to make FOP
behave as one would generally expect... /That/ is simply native XSL-
FO compliance to me.
Cheers
Andreas
