On Oct 1, 2007, at 21:50, Simon Pepping wrote:

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

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.



Reply via email to