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

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.



Reply via email to