Yes, the table height calculation does have a problem if there is word-wrap, which looks like it is happening here. See R4PReportTest>>exampleTableCellVerticalAlignmentOfText2. It's a bit tricky, since the row height needs to be calculated after the content is entered, but the content is not entered until after the table width sizing the calculated. I'll look into it. Bob On Wednesday, November 26, 2014 12:16 PM, Ivo Roefs <ivo@xxxxxxxx> wrote: Hi Bob, I loaded the most recent packages. It's a big improvement eventhough there are still some quirks left. I included the same report as earlier today, this time rendered with the latest packages. If you look at page break from p4 to 5, 1 cell-border&background gets rendered twice, once just before the page break with the first half content of the cell (KRA-), and once just after the page break with the second half of the content of the cell (AN15). I think the entire row should have been rendered after the page break. Still some extra vertical white space here and there. kind regards, Ivo Roefs bobn@xxxxxxxxxx schreef op 26/11/2014 16:15: An updated version of Report4PDF has been published to the Cincom public Store. Note that is code uses the latest released version of Smalltalk4PDF 1.3.1.9 This is a maintenance release with the following changes: - added check if header size exceeds page size; prevents infinite loop - changed column width calculation to treat widget percent as fixed width. Two tables with same width percent will now look the same. - added 'white' as color name - added nil set for CreatedData and ModDate to SUnit test byte array build to avoid false SUnit fails - changed row height calculation to exclude row spacingTop and spacingBottom. Caused extra white space. - updated code to work with the latest version of Smalltalk4PDF (1.3.1.9) ... Matrix uses scaling: instead of scale: (see transformCoordinates). Bob Nemec