[reportlab-users] Difference between Table and LongTable

Félix Labrecque felixl at densi.com
Wed Aug 3 12:02:37 EDT 2011


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>


More information about the reportlab-users mailing list