[pdf4st] Re: unwanted page breaks

  • From: Ivo Roefs <ivo.roefs@xxxxxxxxx>
  • To: pdf4st@xxxxxxxxxxxxx
  • Date: Thu, 16 Aug 2012 16:44:48 +0200

Bob,

I just loaded the latest version.... and it works!!!
Thank you so much.

Did you notice my other remark regarding the alignment of the autonumbering?
    "I also discovered a second minor problem. The alignment in the footer is 'right',
        but apparently there still some extra space on the right side of the page numbering."

Ivo



Op 16/08/2012 15:34, bobn@xxxxxxxxxx schreef:
Ivo,
Thanks for the code... nice catch on the bug.

The problem was caused by the 'check for vertical space' not matching the 'build output' code. It was a challenge to deal with page breaks that could happen in deeply nested layouts. So, instead of trying to unwind a build when a page break happens, the code checks to see if a layout can be added to the current page before the output is created. In this case, the row with content after 'cell1OfDocNr1' checked if it could fit but did not add its own padding to the calculation. Then, when the output for the next cell was created, it triggered an unexpected page break.

The code change was from... 

canBuildAt: aNumber limit: aMaximumY
"is there room for the first section?"

((aNumber + self spacingTop) roundTo: 0.01) >  (aMaximumY roundTo: 0.01) ifTrue: [^false].
self layoutSections isEmpty ifTrue: [^true].

^self sections first canBuildAt: aNumber limit: aMaximumY

...to...

canBuildAt: aNumber limit: aMaximumY
"is there room for the first section?"

((aNumber + self spacingTop) roundTo: 0.01) >  (aMaximumY roundTo: 0.01) ifTrue: [^false].
self layoutSections isEmpty ifTrue: [^true].

^self sections first 
canBuildAt: aNumber + self spacingTop
limit: aMaximumY

Your code has been added to the test examples as exampleTableWithMixedPageBreaks.
All the previous examples still match their previous outputs, so this change did not harm.

New versions of Report4PDF and Report4PDF-test (1.0.2) have been published to the Cincom public Store.

Bob


From: Ivo Roefs <ivo.roefs@xxxxxxxxx>
To: pdf4st@xxxxxxxxxxxxx
Sent: Wednesday, August 15, 2012 1:55:14 PM
Subject: [pdf4st] Re: unwanted page breaks

Hello Bob,

Thanks for the swift response.
I tried some debugging using the methods you described but I can't figure it out.
Attached you can find a fileout of a class which reproduces the problem, starting from page 4.

I also discovered a second minor problem. The alignment in the footer is 'right', but apparently there still some extra space on the right side of the page numbering.

If you could find the time to look into this, it would mean a lot to me.

kindest regards,
Ivo Roefs

Op 15/08/2012 14:52, bobn@xxxxxxxxxx schreef:
Hello Ivo,
Nice to see Report4PDF being used. 

The cell page break code checks to see if a cell will fit on the current page, given where the current Y value is, using #checkFitSpacingTop: 
If the cell is too tall, a page break is triggered. So the interesting question is why was the cell considered too tall for the remaining page height. 
Since you know which page has the first problem, you can put a conditional break which checks the #currentPageNumber in R4PBuilder>>buildCell: just prior to  #checkFitSpacingTop:

The #resetCurrentYAfter: wrapper method is used to go back to the previous Y value after a cell is done being built. That way the next cell is a row is placed in the correct vertical position.
You can send #traceToTranscript or #traceToFile: to the report to see what the output is. The trace shows the calculated page height which is used by R4PCell>>canBuildAt:limit: 

If you can generated an example that causes the problem I'd be happy to look into it.

Hope you find this helpful, 
Bob Nemec


From: Ivo Roefs <ivo.roefs@xxxxxxxxx>
To: pdf4st@xxxxxxxxxxxxx
Sent: Wednesday, August 15, 2012 5:58:11 AM
Subject: [pdf4st] unwanted page breaks

Hi,

I've been exploring Report4PDF (PDF4Smalltalk)....This looks very promising indeed.
I'd like to congratulate the people who put all their effort into it.

I bumped into a small problem.
As you  can see (hopefully) in this screenshot...after 12 pages of correct behaviour.... suddenly there's an unexpected page break after the first cell.
Also for the next three columns there's this unexpected page break.
It appears that with the problematic cells, that they start slightly higher than on other pages.
After that everything's fine again for a number of pages, and then the same problem gets repeated.

I've been looking into some methods like, #checkFitSpacingTop:   #findPageToFitRowTop:, but I really don't know what to look for.

Can anyone give any pointers what could be wrong here?

regards,
Ivo Roefs









Other related posts: