good investigative work, but I fear those tests are way too simple to dare apply the patch.

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.

And has anyone been able to produce a smaller 1 page example of the document - we are stumbling blindly here.
Do we have an odf snippet of the table that gives the problem?

Still not the description i was looking for. I want to know what the extreme case is and what the resulting document should look like when we give up:

In facts that's 2 crashes, first one in ascent, second one misfit.

In D15428#378432, @boemann wrote:

No you misunderstand. I wasn't talking about you diff - I want to know what it is we are trying to accomplish. in spoken words

No you misunderstand. I wasn't talking about you diff - I want to know what it is we are trying to accomplish. in spoken words

@danders you can commandeer this revision to update diff.

In D15428#378422, @boemann wrote:

Dan I like your diff better - I don't think it's completely there but it's a better starting point

On a more conceptual level, what should happen if the design of table is such that headers can't fit on a virgin page? What should we do.? One one hand it should be there but on the other hand we will never get to show the real part of the table ever.
What is the solution we should aim for?

In D15428#378420, @anthonyfieroni wrote:

Yep, it's look like same approach to mine, did you try mine or it's not correct in all cases?

Dan I like your diff better - I don't think it's completely there but it's a better starting point

Yep, it's look like same approach to mine, did you try mine or it's not correct in all cases?

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 ...

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.

@danders that was one of my previous approach. Let @boemann tolds us which is correct one.

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:

Would it be possible to make a unit test?

Ok, let not make whitespace commit. @ognarb just be more precise next time.

Ping

Please add the bug report ID to the commit message, see for example:
https://cgit.kde.org/calligra.git/commit/?id=f1e95f48e44ed548b41ab855432cb57d9c79eee9

Looks good to me.

Related bug: https://bugs.kde.org/show_bug.cgi?id=399569

Deleted one of the two accidentally double-pasted xml content.

Anyone who has already pulled in the latest changes will need to forcibly reset their local working tree after the force push is completed.
Should they have staged work, this would need to be rebased, which can be a non-trivial process and one many developers will not be familiar with.

In D16721#356863, @bcooksley wrote:

Force pushes are generally reserved for pretty serious issues, couldn't the whitespace be corrected with a follow up commit to remove it?

But it's not only that https://phabricator.kde.org/R8:a7ee6f871af225fd5edc9458ee183604fabadc8a
Notice ~SectionLayout() and many others, you should use settings that trim whitespaces on file save. In Kate -> settings -> open/save -> Remove trailing spaces -> In entire document.

Force pushes are generally reserved for pretty serious issues, couldn't the whitespace be corrected with a follow up commit to remove it?

Please contact @bcooksley to remote all white space changes from you commit. Please be more precise when you commit, you introduce even more white spaces rather than to remove them.

In D16721#356813, @anthonyfieroni wrote:

Please, remove all white space changes before commit. It will be better if you test the patch some time without crash or other downsides. If you notice something wrong write here. If all is good you can commit in few days. Thank you for patch, other patches are welcome.

Remove all whitespace

Please, remove all white space changes before commit. It will be better if you test the patch some time without crash or other downsides. If you notice something wrong write here. If all is good you can commit in few days. Thank you for patch, other patches are welcome.

In D16721#356755, @anthonyfieroni wrote:

Can you add screenshots of horizontal and vertical version, add it to test, just to have how it looks. I see some gestures that i cannot test, did you can, touchscreen, tablet or something that this code works :)

Fix

Can you add screenshots of horizontal and vertical version, add it to test, just to have how it looks. I see some gestures that i cannot test, did you can, touchscreen, tablet or something that this code works :)

In D16721#356595, @anthonyfieroni wrote:

Can you test my suggestions, it's looks good to me.

Apply change according to review

Can you test my suggestions, it's looks good to me.

Revert a bit more

In D16721#356162, @anthonyfieroni wrote:

Config, if it's not set explicitly, <appname> + "rc" https://api.kde.org/frameworks/kconfig/html/kconfig_8cpp_source.html#l00607

Config, if it's not set explicitly, <appname> + "rc" https://api.kde.org/frameworks/kconfig/html/kconfig_8cpp_source.html#l00607

About the config for the KoKineticScroller. Do you perhaps know where to find the .kcfg file from calligra?

In D16721#355600, @anthonyfieroni wrote:

Return QObjects, if you have problems copy linker output here.

Removing useless arg

Remove bad code

Return QObjects, if you have problems copy linker output here.

In D16721#355367, @anthonyfieroni wrote:

I'm adding Krita as reviewer, because Karbon is unmaintained and I hope someone at Krita as some experience with the toolbox

I'm the maintainer of Karbon, for now.

Fix some indentation problem

Revert more change

Revert foreach and remove whitespace

Rever foreach

Revert some change more to come

I'm adding Krita as reviewer, because Karbon is unmaintained and I hope someone at Krita as some experience with the toolbox

Ok, after some more investigation, I've found a number of problems around these things.
This was really just a bug in the stencil database.odg file.
The callout stuff is the big one, because it abuses odf so needs special treatment.
I'll just call this patch a false start and abondone it.

In D16406#349051, @arojas wrote:

In D16406#349046, @aacid wrote:

When you say "But this one needs to be fixed in the 3.1 branch too" you mean D16406 (i.e. this very same patch) or the compilation error because of the overrides?

I mean this one, the other error doesn't happen in 3.1 since you only pushed the changes to master

In D16406#349046, @aacid wrote:

When you say "But this one needs to be fixed in the 3.1 branch too" you mean D16406 (i.e. this very same patch) or the compilation error because of the overrides?

When you say "But this one needs to be fixed in the 3.1 branch too" you mean D16406 (i.e. this very same patch) or the compilation error because of the overrides?

Indeed git master doesn't build with 0.55:

Looks good, since you seem to have a pre 0.64 build at hand, could you check it still actually builds after i added all the overrides? Maybe we need some more ifdef

Invert conditional

I'd say let's go with what René suggested, i guess it what makes more sense.

I don't mind either way. In the future this could be changed to VERSION_GREATER_EQUAL when this can depend on cmake 3.7

In D16388#348767, @pino wrote:

In D16388#348765, @rikmills wrote:

Build failure:

See D16406: Fix build with poppler<0.64.

In D16388#348765, @rikmills wrote:

Build failure:

Build failure:

How about

Check for poppler version at cmake time

Please do a feature test at cmake time instead.

i'm really wondering how broken SvgOutputDev.h is since we've changed the API a bit i think. If it's not using override i guess suddenly stopped overriding functions and noone realized...

Yes, found it: https://bugs.kde.org/show_bug.cgi?id=289646
Afaics this affects only callout shapes where OO/LO breaks the intention of the odf spec
by using the shape size and position as text area.
This is ok (sort of) when text area and shape area overlap but not when part of the path goes outside
the shape area as with callouts.
The current code fixes this but we also get false positives as demonstrated.
I'll try to find a more specific way to handle this.
I doubt LO will fix this, ever, so we have to live with it, but I *hate* working around bugs in other apps.

As I recall it was one of the files in the huge dataset - there should be a bug on it

I have tested with LO:
Create with flow,
Open in LO,
Save in LO,
Open in flow.
And it seems to work, so there must be some special case?
The only workaround I've seen is for ellipses.
No chance for a testdoc I guess...