Vincent Hennebert wrote:
Hi All,
Hi Vincent,
While I am making rather good progress on my prototype implementation of a new layout approach, I am not likely to get any practical results before some time (a year or more). Meanwhile, users keep bumping into this Changing IPD issue, which is becoming more and more problematic. It would be good if we had some partial, temporary solution with which users could live until the new approach has been implemented. In many cases, the ‘Changing IPD’ problem boils down to the first page of the sequence having some sort of side region encroaching upon the main content, and all the following pages having the same width. And the content is usually made of just plain text (fo:block elements).
I have also seen use cases along those lines.
I spent some time looking at the current code and it seems to me that a hack could be implemented without too many difficulties. It basically consists in 2 steps: 1. in the Knuth breaking algorithm, when creating a new active node, look whether the IPD for the following page is the same or not. If not, deactivate the node. Once we run out of active nodes, select the best of those deactivated nodes and treat it as if it were the regular final node. Add areas for content up to that node. 2. re-create Knuth elements, starting from the index corresponding to that node. Re-launch the breaking algorithm, starting from there. Then back to step 1, until the end of the document is reached. Step 1 should be doable without turning everything upside down. Step 2 implies to change the signature of the LayoutManager.getNextKnuthElements method, adding a parameter that corresponds to the index from where to start the generation of Knuth elements. We could largely ignore it, except in BlockLayoutManager where we would re-launch the line-breaking algorithm, taking the new IPD into account.
I can't offer much technical help with the above as I'm not familar with those areas of the code.
Obviously this is a limited approach. There is likely to be a (potentially huge) waste of CPU cycles due to the re-creation of Knuth elements. There may be side effects that I’ve missed so far. But I think it’s worth giving it a try.
Will the increase in CPU cycles only occur if there is a change in IPD, or will this affect performance for existing users with the same width on every page?
What I’m planning to do is create a branch in which I would experiment that idea. If it turns out to be feasible then we could merge it back to Trunk, advertise the ‘fix’ and document its limitations. And hopefully that will relieve some pressure on the implementation of the more complete new approach.
Thanks, Chris
