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
[1], 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

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.


[1] (especially
the "Limitations" section)

Reply via email to