Bug 112346 - FILEOPEN DOC: a table is imported into a frame; second page is missing
Summary: FILEOPEN DOC: a table is imported into a frame; second page is missing
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Mike Kaganski
URL:
Whiteboard: target:6.0.0
Keywords: filter:doc
: 81498 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-09-12 10:46 UTC by Mike Kaganski
Modified: 2017-10-07 20:48 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Two-page table (27.00 KB, application/msword)
2017-09-12 10:46 UTC, Mike Kaganski
Details
Yet another DOC example (136.10 KB, application/msword)
2017-09-13 15:07 UTC, Timur
Details
Artikelliste exported as PDF in master 6.0+ has 9 pages (50.27 KB, application/pdf)
2017-09-15 13:34 UTC, Timur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2017-09-12 10:46:50 UTC
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)
Comment 1 Mike Kaganski 2017-09-12 10:59:30 UTC
A patch is in gerrit: https://gerrit.libreoffice.org/42196
Comment 2 Commit Notification 2017-09-12 12:29:31 UTC
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.
Comment 3 Timur 2017-09-13 13:24:54 UTC
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].
Comment 4 Mike Kaganski 2017-09-13 13:53:08 UTC
(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.
Comment 5 Timur 2017-09-13 14:58:53 UTC
*** Bug 81498 has been marked as a duplicate of this bug. ***
Comment 6 Timur 2017-09-13 15:07:36 UTC
Created attachment 136229 [details]
Yet another DOC example

Looks like this one fixed also attached DOC I previously thought was Bug 78756.
Comment 7 Timur 2017-09-14 16:54:51 UTC
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.
Comment 8 Mike Kaganski 2017-09-14 17:05:55 UTC
(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.
Comment 9 Timur 2017-09-15 13:34:31 UTC
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.
Comment 10 Aron Budea 2017-10-07 20:48:08 UTC
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.