[reportlab-users] Flowing onto second column

Robin Becker robin at reportlab.com
Thu Feb 14 11:30:18 EST 2008

Jim Steil wrote:

> Robin Becker wrote:

>> Jim Steil wrote:

>>> Tim Roberts wrote:

>>>> Jim Steil wrote:


>>>>> Is there an easy way to get data to flow to a second column the way

>>>>> you can get it to flow to multiple pages with Platypus?


>>>> Sure. You just create multiple frames, one for each column, and add

>>>> the collection of frames when you create the PageTemplate.


>>>> Here's a web page that shows an example:

>>>> http://www.hoboes.com/Mimsy/?ART=558


>>> Ok, I'm trying to get my report working per the instructions at the

>>> link above. However, I've changed it a bit because instead of having

>>> paragraphs display in my columns, I have tables that I want to snake

>>> around the columns. So, where this doc refers to paragraphs in the

>>> 'items' list, I'm appending tables. But, when I get to the

>>> document.build(posts) statement, I get the following dump:


>>> Traceback (most recent call last):

>>> File "C:\PyWork\Motion\motion\utility\priceSheet.py", line 187, in

>>> <module>

>>> priceSheets(filename)

>>> File "C:\PyWork\Motion\motion\utility\priceSheet.py", line 178, in

>>> priceSheets

>>> go(doc, c)

>>> File "C:\PyWork\Motion\motion\utility\priceSheet.py", line 167, in go

>>> doc.build(allData)

>>> File

>>> "c:\python25\lib\site-packages\reportlab\platypus\doctemplate.py",

>>> line 749, in build

>>> tr.srcFile,

>>> AttributeError: Field instance has no attribute 'srcFile'


>>> I'm stumped as to where I should look for the problem. Can anyone

>>> give me any clues?

>> .......

>> well tr is obtained because the erroneous flowable was given some sort

>> of _traceInfo. That should be an object with the following attributes


>> srcFile,startLineNo,endLineNo,endLinePos


>> if it doesn't have those attributes then an error will result. I don't

>> think there's any way that _traceInfo can be non None unless it's

>> being set somewhere deliberately. Just create a tracing class and use

>> that instead of a simple string or whatever. I suppose we could

>> consider allowing _traceInfo to be a simple string of your choosing

>> and using that rather than a structured object. I have to confess I

>> know little (or perhaps have forgotten) about this code. I suspect in

>> the modern world we'd just make _traceInfo something with a __str__

>> method (or a str).

> So, are you implying that I should be looking into the doctemplate.py

> and find a better solution to the reportlab code? I don't think I have

> the depth of knowledge necessary to take that on. Or, are you saying

> that I'm giving it a bad flowable that is causing the problem? If so,

> how could I identify that?

no I'm saying I don't know how you managed to end up with this tr._traceInfo
problem. I just checked most of our code base and the only refs to _traceInfo
are in doctemplate.py and flowables.py. Every flowable is supposed to descend
from Flowable which has an initial setting of _traceInfo to None. The code in
doctemplate is then only supposd to try and refer to x._traceInfo if 1)
hasattr(x,'_traceInfo') is True and 2) x._traceInfo is non-zero. If that's the
case then we attempt to pull those attributes of the _traceInfo object and
incorporate them into the current traceback. That's so we get a more detailed
error message when a particular flowable is putting this _traceInfo onto itself
with some meaninful info (like which file it came from and where etc etc).

So is there anywhere in your code where _traceInfo is mentioned?
Robin Becker

More information about the reportlab-users mailing list