Created attachment 136197 [details] Two-page table The attached document (containing a table that spans two pages) is imported into a frame, and the resulting document has only a single page. Tested with Version: 5.4.1.2 (x64) Build ID: ea7cb86e6eeb2bf3a5af73a8f7777ac570321527 CPU threads: 4; OS: Windows 6.19; UI render: default; Locale: ru-RU (ru_RU); Calc: group and also OpenOffice.org 3.3.0 OOO330m20 (Build:9567)
A patch is in gerrit: https://gerrit.libreoffice.org/42196
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a952d1f59f4f84380b82f1eb9e550b8f69c4be5d tdf#112346: take Word no-wrap limit into account also for ww8 It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified. Can it be that this also fixed table overlap for attachment 100027 [details] from Bug 78401? That looks good now, only somewhat moved left. Please confirm. I'll open another bug for attachment 135593 [details].
(In reply to Timur from comment #3) > Can it be that this also fixed table overlap for attachment 100027 [details] > from Bug 78401? That looks good now, only somewhat moved left. > Please confirm. I'll open another bug for attachment 135593 [details]. It definitely affects that attachment. But it does not fix the underlying problem - which my Bug 112359 is also about. My patch makes more tables to be imported as normal, not floating, tables. That may be a good thing, that will improve many documents. But the overlap should not have happened in the first place, and that's a bug of its own.
*** Bug 81498 has been marked as a duplicate of this bug. ***
Created attachment 136229 [details] Yet another DOC example Looks like this one fixed also attached DOC I previously thought was Bug 78756.
Mike, can you please check attachment 118608 [details] from Bug 94135? I guess it's your fix that made it look better, but it's 9 pages instead of 2. Just to be sure it's not some regression from this one, because it never had 9 pages.
(In reply to Timur from comment #7) > Mike, can you please check attachment 118608 [details] from Bug 94135? > I guess it's your fix that made it look better, but it's 9 pages instead of > 2. > Just to be sure it's not some regression from this one, because it never had > 9 pages. 9? I see 3. If we speak of those 3 pages, that is not a regression. LO had always imported one of the tables (the one below a wide horizontal line, single-line in Word, with text "Hier ist Schluss bei Modebasar.") as multi-row Table4 (with 21 rows). If you open it with 5.4, and make all frames to have no wrap, you will see that it is already wrong.
Created attachment 136265 [details] Artikelliste exported as PDF in master 6.0+ has 9 pages Attachment 118608 [details] from Bug 94135 as seen and exported as PDF in master 6.0+ has 9 pages. Not Export blank pages dependant.
Using bibisect repo bibisect-win32-6.0 I can confirm that the document from bug 94135 showing 9 pages (most of them empty) started with the commit from comment 2. The tables also look slightly different than with 5.4.2.2 and turning off Page Wrap for all of them. Mostly that in the table doesn't last until the edge now.
*** Bug 80348 has been marked as a duplicate of this bug. ***