Patch for when rowspan or colspan equals 0

[Carlos Licea]

Dear list,
	I've been working on my patch for implementing proper colspan and rowspan 
behaviour.
	Forget almost completely my previous mail, here's a new way of doing it, way 
better than the old one, which has no known corner-cases, it even handles 
properly when both colspan and rowspan equals 0 in the same cell, whereas the 
last one did but I couldn't catch them till recently.
	In essence the method now is:
	->If we found a colspan = 0 we insert the cell and take ownership of all the 
cells to the right that exist so far, update the colspan properly and insert 
it in the QMap as such QMap<nextColWhenUpdateIsNeeded, cell>.
	->Similarly for rowspan = 0, except that since the rows are sequential 
whenever we find a row with such rowspan it has to be from that point on, it's 
inserted similarly: QMap< nextRowWhenUpdateIsNeeded, cell>.
	->On the next pass we check whether we're in an unhandled column for any of 
the colspan=0 cells, if so, update properly (update its colspan and mark as 
used the cell). We check the same for rowspans and store the column in which 
no other cell should be placed.
	->Process cell as usual, except if we're in a column in which no cell should 
be inserted then advance to the next column.
The only corner case for both colspan and rowspan cells happens when it's a 
new column in which we are dealing, that is we are at a position in which no 
column has been inserted so far. Of course it is properly handled inserting a 
new column.

So the algorithm seems to work quite well actually, except for one problem, 
for rowspan > 2 for some reason it stops growing the cell even though we set 
the rowspan properly! (I believe but my believings have been proven wrong in 
the past ;).
	So we're this time _really_ nearly there. I'm attaching you the bunch of test 
cases I've covered, and passed, so far (the previous ones had some 
misspellings and I didn't realize till after sending the previous mail so it 
lead me to the wrong conclusion that the previous algorithm worked, now I 
believe they're actually right), also the test in 
http://bugsfiles.kde.org/attachment.cgi?id=8334 is passed too except for the 
fact that rowspan doesn't seem to want to grow greater than 2.
	I'll let you know if I could solve the rowspan > 2 problem, if so then the 
patch wouldn't have any known problems, and would be waiting just for the 
regression test to be commited.
--
Carlos

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20090403/9225ae02/attachment.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20090403/9225ae02/attachment-0001.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20090403/9225ae02/attachment-0002.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20090403/9225ae02/attachment-0003.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20090403/9225ae02/attachment-0004.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20090403/9225ae02/attachment-0005.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tables.diff
Type: text/x-patch
Size: 9196 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20090403/9225ae02/attachment.bin>