[PATCH]: Table::apportionRowSpan()
OK, please ignore my previous attempt at reworking Dillo's ROWSPAN handling. I have a simple fix for the bugs I reported at http://starurchin.singularity/dillo/bugs/table_rowspan.html . This patch tweaks dw::Table::apportionRowSpan() to handle the special case where all the rows being spanned have zero height. This fixes the special cases that were breaking without changing the behaviour in any other case. (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.) Regards, Jeremy Henty
On Fri, Feb 01, 2008 at 06:10:39AM +0000, Jeremy Henty wrote:
OK, please ignore my previous attempt at reworking Dillo's ROWSPAN handling. I have a simple fix for the bugs I reported at http://starurchin.singularity/dillo/bugs/table_rowspan.html . This patch tweaks dw::Table::apportionRowSpan() to handle the special case where all the rows being spanned have zero height. This fixes the special cases that were breaking without changing the behaviour in any other case.
Committed.
(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. -- Cheers Jorge.-
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. Regards, Jeremy Henty
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.-
On Fri, Feb 01, 2008 at 06:11:58PM -0300, Jorge Arellano Cid wrote:
On Fri, Feb 01, 2008 at 07:49:43PM +0000, Jeremy Henty wrote: The "obvious right thing" may vary. For instance, what the algorithm currently does is to proportionally apportion the extra space (just as Firefox).
Good point! I was thinking of sharing the space equally rather than proportionally, but proportionally is better. I think I'll be able to do that in O(n). I've put the rewrite on the back burner for now, as its priority has dropped since the actual breakage that starting me thinking along these lines has been fixed. Regards, Jeremy Henty
participants (2)
-
jcid@dillo.org
-
onepoint@starurchin.org