> -----Original Message----- > From: Luca Furini [mailto:[EMAIL PROTECTED] >
Hi, <snip /> > I don't know if the methods could be moved to the FLM: besides the break > value, they depend on the current page number and this is known only by > the PageSequenceLM. Yeah, it was just a thought... I assumed the FlowLM was the place where the actual breakValue was resolved before it was passed to PSLM.needEmptyPage() or .needNewPage() --but looking closer, that's not how it works... (PSLM.handleBreak() is a private method). > The method needEmptyPage() should return true only when we are starting > the layout of a different subsequence, and the next page would not be of > the right kind. Further browsing leads me to place my money on AbstractBreaker.BlockSequence. If I get it correctly, the 'startOn' value is set only once for the entire list (at construction time), but that value is returned every time the PSLM.PageBreaker calls BlockSequence.getStartOn() --which happens in PSLM.PageBreaker.startPart() line 205. So, if this method is called every time a new page is created, and *one* BlockSequence spans multiple pages, we would get the wrong breakValue for all pages but the first... Still looking for the optimal way to correct this behaviour. Would we need a 'check' on whether the previous page already contains areas generated by elements of a given BlockSequence (or: whether the first area on curPage is also the first area generated by an element of the BlockSequence)? <snip /> > > [Glen :] > > the FLM is the immediate LM child of PSLM, so it > > should have everything that PSLM does (except for the > > static content, which I don't think we care about when > > it comes to page breaking anyway.) Ideally, FLM > > should be the topmost LM that handles the page > > breaking, no? I wonder if the Knuth code should be > > out of PSLM completely > > I need some more time to reflect on this idea, but I write a quick answer > anyway. > > My first impression is that I would find somewhat strange that the *page* > breaking is not in the *Page*SequenceLM! :-) > > A more serious comment is that some formatting objects (footnotes and > before floats) generates "page-level-out-of-line-areas", whose placement, > according to the recommendation (4.2.5), "is controlled by the > fo:page-sequence ancestor"; so, if the PSLM must handle footnotes and > before floats (influencing the available bpd for the normal areas) it must > handle the whole page breaking process. Both very good points! Let's keep it exactly where it is. Cheers, Andreas
