Hi All, 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 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. 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. 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. Thoughts, anyone? Thanks, Vincent
