[reportlab-users] bugfix for reordering problem

[Robin Becker]

On 28/01/2010 12:52, Matt Folwell wrote:

> On 28/01/2010 10:52, Robin Becker wrote:

>> On 27/01/2010 16:32, Robert Hölzl wrote:

.........

>

> Robert's SmartKeepTogether is trying to do this:

>

> If the content fits in the current frame, just issue the content.

>

> If the content doesn't fit in the current frame, but we're already at

> the top of the frame, just issue the content and let it overflow.

>

> If the content doesn't fit in the current frame, and we're not at the

> top, issue a break + the content.

>

> It handles the last 2 by always issuing a NotAtTopPageBreak

>

>

> The problem would be clear if he'd added another flowable to his story,

> like the attached. The page break is delayed until after the contents of

> the SmartKeepTogether.

>

>

> The problem comes from how generated content interacts with split():

>

> Normally we pop a flowable from the front of the flowables list and

> handle it. Then, if it produced any generated content, the is inserted

> at the start of the flowables list.

>

> When a flowable splits, we immediately handle the first item produced,

> and insert the rest at the start of the flowables list.

>

> But if the first item from the split produces generated content, that

> gets inserted at the start of the flowables list, and then the rest of

> the split gets inserted before it.

>

> Robert's patch reverse the order of those two inserts, so in the

> resulting flowables list you get the generated content from the first

> split item before the rest of the split items.

>

>

> A couple more questions:

>

> If frame.split() is allowed to add generated content where should that

> content go? Possibly another call to _addGeneratedContent is needed there.

>

> Line 775 of doctemplate.py postpones handling PageBreaks and

> ActionFlowables when they're the first item of a split. Should that also

> apply to FrameActionFlowables?

>

> That would solve this instance of the problem, but it would still remain

> if non-action flowables add generated content.

.......

I don't see the problem with this example at all since we aren't generating any 
content and the problem doesn't arise unless we try to add the first split item.

 From examination of the two coding sequences it seems that we're really talking 
about the order in which the frame generated content from S[0] appears relative 
to S[0] and S[1:] when S[0] is successfully added. I think the current 
implementation is wrong so the patch will be implemented. Thanks for the fix, 
and patient explanations.

On the issue of whether we should treat the FrameActionFlowables with deferral 
to the main loop I don't think so. The reason for deferring the instances of 
PageBreak,SlowPageBreak,ActionFlowable is that we have special treatment for 
those at the top of the loop. So far as I know we can handle the 
FrameActionFlowables in the ordinary way.
-- 
Robin Becker