- User Since
- Aug 22 2016, 1:56 PM (126 w, 1 d)
Fri, Jan 18
Thu, Jan 17
Ran this patch against new unit tests and it fixes all the expected ones, namely those where all cells in first row is merged with cells in second row.
Test results without patch: https://build.kde.org/job/Calligra/job/calligra/job/kf5-qt5%20SUSEQt5.10/lastCompletedBuild/testReport/projectroot.libs.textlayout/tests/libs_kotextlayout_TestTableLayout
See uploaded file for result with patch.
Wed, Jan 16
I would like to wait with this if there is not a compelling issue like bugs.
Calligra uses this and tries to stay conservative due to some users using old qt.
Tue, Jan 15
Even if they do not all pass, I think they should be commited if the tests/methods are ok and the reason for not passing are genuin bugs, no?
Fri, Jan 11
Thu, Jan 10
Add a test that trigger a loop in the table layout
Tue, Jan 8
No, all do not pass, generally when the first row is merged, layout fails.
(I am trying to provoke problems similar to bug 381341 that we have tried to fix in D15428.)
Not trivial (for me) to get data out of layout so it is hard to create robust tests.
I don't think I have been able to create a test to simulate the loop excactly.
Also, uncertain wether the MockRootAreaProvider is sufficient.
Any ideas/comments wellcome.
Fri, Jan 4
Could yo remove lines 178-181 too?
Dec 20 2018
Dec 18 2018
Fidled a little more with this, and found several problems when table with merged cells is split over pages,
like unmerged cell painted on both pages (empty on first page), caret not shown in selected cell and sometimes shown in prev cell.
Dec 17 2018
I ended up in the same spot as you:
Since all columns in row 0 spans rows, totalMisFit will always be set to true and the whole table is layed out on next page, and next page again and again ...
Dec 14 2018
Ok, think I'm on to something.
Testing with the 1.doc in bug 381341. It seems it fails on the table in approx page 222 (open in LO)
with text in 0,0: Экономический субъект
Stepping through the KoTextLayoutTableArea::layoutRow(), it seems *all* columns in row 0 (at least) spans rows and hence (I think) layouting does not work.
Dec 12 2018
Had a closer look at this. Afaics we get an infinit loop when a table is 'totally misfit',
Can't say I understand the table layout logic, but my assumption is that if a row is a total misfit it can't just be ignored,
so breaking off the row layout loop in this case seems to work:
Dec 9 2018
Would it be possible to make a unit test?
Nov 19 2018
Nov 16 2018
Nov 15 2018
Nov 14 2018
Nov 13 2018
No action, so maybe I created this in the wrong way?
Nov 12 2018
Nov 9 2018
Nov 8 2018
Nov 7 2018
Nov 5 2018
Nov 1 2018
Yes, I have patch for nullptr, not pushed yet.