Just back online. On Thu, Jun 11, 2009 at 04:57:27PM +0200, Andreas Delmelle wrote: > On 11 Jun 2009, at 12:40, Vincent Hennebert wrote: > > Hi Vincent > > <snip /> >> 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. > > If I interpret correctly, we would (supposing a page-sequence without > forced breaks and/or span changes): > > a) generate the complete block list (effectively computing the line- > breaks for the whole page-sequence) > b) when computing the page-breaks, and encountering a new page with > different available IPD, re-generate the remaining elements and > recompute the line-breaks after that position > > b) would occur as many times as we have IPD changes.
I get the feeling that this means that you are planning to relaunch line breaking while in the page breaking phase. Is that possible? It is a bit strange that changing IPD would waste CPU cycles, as it could be achieved by the simpler of two strategies, best-fit versus total-fit. But maybe implementing best-fit next to total-fit would be more than a simple solution. I agree that it would be an improvement to have even a partial solution for the changing IPD feature. Good luck with this necessary job. Simon -- Simon Pepping home page: http://www.leverkruid.eu
