On Wed, Apr 20, 2005 at 05:51:47PM +0200, Luca Furini wrote: > Simon Pepping wrote: > > > 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.
Indeed. Another idea is that PSLM.addAreas calls the addAreas method of each of its children, as it does now, but also passes the page break Position. Then the LMs continue to add areas until one of them reaches the page break Position. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
