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
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
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
|