[reportlab-users] Spreadsheet Table

[Tomasz Świderski]

Andy Robinson wrote:

> A LOT of things get easier when colWidths are given.   Similarly, if

> we allow extra rows to be introduced on splitting (repeatRowsB?),

> maybe we should require that they have an explicit height declared by

> the programmer.     I imagine this would work for 99% of real world

> cases.

>   

repeatRowsB is short from repeatRowsBottom ;)

I believe requiring from programmer to declare cell dimensions of 
repeated rows is not necessary. Main purpose of platypus it to shield 
programmer from low-level API. Cell dimensions depends on applied 
styles. And style class can be dynamically built long after table 
creation - possibly by other user/function.  Programmer may not know 
what styles will be applied to his table - so will be unable to "guess" 
cell dimensions. And he will have to deal with low-level API (like 
stringWidth) to provide correct dimensions - this work should be done by 
platypus. As long as cell dimensions are static, there is no problem 
splitting tables with bottom repeated rows. Let me show you how I did 
that in spreadsheet table:

    def _getFirstPossibleSplitRowPosition(self,availHeight):
        h = sum(self._rowHeights[:self.repeatRows]) # height of top 
repeated rows
        h += sum(self._rowHeights[self._nrows-self._repeatRowsB:]) # 
height of bottom repeated rows

        split_at = 0 # from this point of view 0 is the first position 
where the table may *always* be splitted
        for n, rh in 
enumerate(self._rowHeights[activeRows0:self._activeRows[1]]):
            if h+rh>availHeight:
                break
            if not impossible.has_key(self._vis_to_abs(n+self.repeatRows)):
                split_at=n + 1
            h=h+rh
        return split_at

So you first calculate height required by repeated rows top and repeated 
rows bottom. Then you try to fit as many rows as possible into remaining 
space (between repeated rows top and bottom).



I'm aware, that dynamic values (introduced by Formulas) can vary in size 
so I "solved" it by reproducing other spreadsheet software behavior. 
Simply user declare longest possible value of formula cell. Cell 
dimentions are calculated based on this longest value. On evaluation 
Formula class have all the information required to check if computed 
value will fit into cell. If it won't, Formula class returns '###' 
instead of real value (could rise exception if needed). So if 
user/programmer want to calculate sum of current page cols - he should 
have idea how big this sum will be. I'm pretty sure that I provided cell 
overflow example with spreadsheettable implementation.

Tomasz Świderski