[reportlab-users] Difference between Table and LongTable

[Félix Labrecque]

I have recently upgraded from the open source reportlab 2.4 to version 2.5

In the release notes, I found this :


      Report Markup Language (RML)

Long table optimisations are now turned on by default. Previously, 
documents with very long tables spanning many pages could take a long 
time to create because we considered the whole table to work out row and 
column sizes. A patch was submitted some time ago to fix this controlled 
by a flag in the rl_config file, but this was set 'off' for 
compatibility. Users are often not aware of this and we haven't found 
any real-world cases where the new layout technique works badly, so we 
are turning this behaviour on.

So in rl_config.py, the longTableOptimize has been set to 1 instead of 0 
in reportlab 2.4

I might have found a case when it behave badly.

Here is an example I did that show the problem: (ran on both windows, 
linux 32 and 64 bits with python 2.7)

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from reportlab.platypus import Table, TableStyle, LongTable
from reportlab.lib.units import inch
from reportlab.lib import colors

font = 'Helvetica'
font_size = 9

style = TableStyle([
                 ('FONT', (0, 0), (1, -1), font, font_size),
                 ('FONT', (-1, 0), (-1, -2), 'Mono', font_size),
                 ('FONT', (0, -1), (0, -1), font, font_size + 4),
                 ('FONT', (-1, -1), (-1, -1), 'Mono', font_size + 4),
                 ('ALIGN', (0, 0), (-1, -1), 'RIGHT'),
                 ('ALIGN', (1, 0), (1, -1), 'LEFT'),
                 ('BOX', (0, 0), (-1, -1), 1, colors.black),
                 ('LEFTPADDING', (1, 0), (-1, -1), 3),
                 ('TOPPADDING', (0, 0), (-1, -1), 1),
                 ('BOTTOMPADDING', (0, 0), (-1, -1), 1),
                 ('LINEABOVE', (0, -1), (-1, -1), 1, colors.black),
                 ('LINEAFTER', (0, 0), (0, -1), 1, colors.black),
                ])


widths = [None, 0.2 * inch, 1.2 * inch]

data = [
         ['SUBTOTAL', 'CAD', '73.76'],
         ['', '', ''],
         ['FREIGHT', 'CAD', '9.95'],
         ['FEDERAL TAX', 'CAD', '10.88'],
         ['', '', ''],
         ['TOTAL', 'CAD', '94.59']
        ]

table = Table(data, style=style, colWidths=widths)

w, h = table.wrap(0, 0)

print 'Optimize : off\n'
print 'Width: ' + str(w) + ' Height : ' + str(h) + '\n'

tableO = LongTable(data, style=style, colWidths=widths)

w, h = tableO.wrap(0, 0)

print 'Optimize : on\n'
print 'Width: ' + str(w) + ' Height : ' + str(h) + '\n'


Give the following result:

Optimize : off

Width: 174.315 Height : 81.6

Optimize : on

Width: 174.315 Height : 12.8


I think both method should return the same height, as they do for the width.

Can you help me find the problem ?

(correct answer should be a height of 81.6, because I have 6 lines of 
content to display)

I am using the wrap function to determine the minimum width and height 
of my table, and I am doing different thing afterward depending on the 
result values
(and I am calling the drawOn() function afterward with the wrap() 
values) so I really need both method to give the same value; else I 
won't be able to upgrade to version 2.5 without reverting the 
optimization and am I guessing that the 'old method' might get 
deprecated in a future version so I either want to correct my code or 
find the bug in reportlab and correct it.

If seems that longTableOptimize force the tables.py/_calc() function to 
only use 1 line, instead of 6, because when I display the pdf, I can 
only see 1 line with longTableOptimize set to on.


Thanks

Félix Labrecque
felixl at densi.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/reportlab-users/attachments/20110803/bae50a02/attachment.html>