Simon Pepping wrote: > I noticed that each line in a paragraph has the height of the first > line of that paragraph. That is not correct, and may invalidate test > files.
You are right, but this can be easily fixed. At the moment each created box has height = constantLineHeight: I added this "trick" in order to simplify the creation of multi-layout sequences , but it is completely unnecessary in normal situations. Each box can be given the right height stored in the corresponding LineBreakPosition. I'll commit a fix by the end of this day. > I also noticed that the whole page sequence is read before pages are > created. Is that going to change, as discussed some time ago? The total-fit strategy (with the PSLM collecting the whole sequence) is much similar to the LineLM behaviour, so it was easier to implement than the other one. As far as I can remember from previous threads, we agreed to start implementing this strategy, and then (as soon as possible) provide an alternative one, to be used in situations where speed is more important than quality, and when the page IPD changes. > I am worried about performance. Knuth elements are passed up and down > the LM tree, and at each step the Position is wrapped or > unwrapped. That probably occurs very many times, and together these > operations could require considerable processing time. Perhaps it can > be avoided. I do not see a fundamental reason why the whole stack of > ancestral LMs should be contained in a Knuth element. Jeremias Maerki wrote: # With just a little additional flexibility in the addAreas() # methods we can probably get rid of the wrapping. A few wrappings could be avoided; for example, I think that the FlowLM could leave the Positions unchanged, as it is the PSLM only child (besides StaticContentLMs). But maybe your idea is much better. PSLM.addAreas would call directly LineLM.addAreas() (or TableContentLM.addAreas(), or ListItemLM.addAreas()) which could make a simple check to see whether there is already a parent area or it must be created calling BlockLM.addAreas(), and so on. The stack of method calls would be turned upside-down. The getParentArea() method, if I remember correctly, already behaves in a similar way: when a LineLM calls getParentArea(), and the area does not exist, the call could be propagated up to the PSLM. Regards, Luca  http://wiki.apache.org/xmlgraphics-fop/MultiLayoutSequence (especially the "Limitations" section)