Hi, On Fri, Feb 01, 2008 at 07:49:43PM +0000, Jeremy Henty wrote:
On Fri, Feb 01, 2008 at 03:15:13PM -0300, Jorge Arellano Cid wrote:
On Fri, Feb 01, 2008 at 06:10:39AM +0000, Jeremy Henty wrote:
(BTW, I still think there is a case for reworking Dillo's ROWSPAN algorithms along the lines I suggested, but it's nice to fix bugs without such efforts.)
If you want to go further, please keep in the O(n) realm.
I will. It is easy to calculate the minimum cumulative depths of the rows in a single pass over the cells, treating all ROWSPAN values in the same way. (In fact it needs only a small modification to the current code: my previous patch was so ridiculously over-engineered that I'm quite embarrassed by it.) The problem is that if you use those depths then you squash everything up to the top, so that when a cell spans several rows all the extra space goes into the bottom row. That might be mathematically correct but it will look just plain wrong.
It is easy to do a second pass from the bottom-up to find the *maximum* cumulative depths (subject to the total height of the table being minimal); the challenge is to find a way to average those two sets of values that (a) does something sensible in all cases, (b) does the obvious right thing in simple cases, ie. if one cell spans n rows then any spare space is distributed evenly between those rows, and (c) takes O(n). I think I can do it, but haven't yet coded it.
The "obvious right thing" may vary. For instance, what the algorithm currently does is to proportionally apportion the extra space (just as Firefox). e.g. <table border=1> <tr> <td rowspan=3> 1<br>2<br>3<br>4<br>5<br>6<br>7<br>8<br>9<br>10<br> 11<br>12<br>13<br>14<br>15<br>16<br>17<br>18<br>19<br>20 <td>A <tr><td>A<br>B <tr> <td>A<br>B<br>C </tr> </table> Although most probably you're thinking of a more complex case. -- Cheers Jorge.-