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

Reply via email to