On Sep 30, 2007, at 22:03, Simon Pepping wrote:

On Sat, Sep 29, 2007 at 08:59:36AM +0200, Andreas L Delmelle wrote:

Either the code in ListItemLM and others needs to be adapted to deal with ListElements instead of KnuthElements, or the ParagraphListElement needs to
subclass KnuthElement instead of ListElement directly.

ParagraphListElements are not supposed be KnuthElements. The error is
genuine. After linebreaking has been applied to ParagraphListElements,
they have been replaced by KnuthBlockBoxes and similar
KnuthElements. Then the CCE will have been removed.

OK, I see. Just got to the conclusion myself that it looks quite simple though: at some point in the process, doLineBreaking() needs to be called to substitute the ParagraphListElements with the corresponding list of KnuthElements. I'm just not sure where to integrate it, yet.

One thing I was wondering about: doLineBreaking() is parameterless for the moment. Do you see this changing in the future? i.e. If this method can be called multiple times on the same paragraph, give it a position to start from the second time? So something like

doLineBreaking(LayoutContext, Position)...?

If I get it correctly now, the LayoutContext is still handled through the LineLM, while somehow I would see the LineLM as receiving the LayoutContext only at the very latest instance. For example, the paragraph-linefiller-width would no longer be stored in the KnuthParagraph itself, but passed into the doLineBreaking() method. (Long shot :S)

Concerning an earlier question/remark by Chris:

On Sep 25, 2007, at 10:19, Chris Bowditch wrote:
The page breaker can implement both the total fit strategy for a page
sequence and the best fit strategy for one page (or a range of
pages). The latter strategy allows one to have different widths for
different pages.

I am curious to know how this works. So if I want to allow changing IPD in a page-sequence, I specify a property on the page-sequence to indicate best-fit instead of total-fit?

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...



Reply via email to