Bug 61594 - FILEOPEN:docx with multi-page floating table (workaround from MS Office: Table Properties - set Text Wrapping to None)
Summary: FILEOPEN:docx with multi-page floating table (workaround from MS Office: Tabl...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.0.0.0 beta1
Hardware: Other All
: high enhancement
Assignee: Miklos Vajna
URL:
Whiteboard: BSA target:7.6.0
Keywords: bibisected, bisected, filter:docx
: 60342 71584 74915 94951 112004 112544 116096 143729 143743 144976 148034 151517 155027 156957 (view as bug list)
Depends on:
Blocks: DOCX-Floatingtable 155118
  Show dependency treegraph
 
Reported: 2013-02-28 09:10 UTC by Peter De Wachter
Modified: 2023-10-12 06:36 UTC (History)
26 users (show)

See Also:
Crash report or crash signature:


Attachments
Test document (35.38 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2013-02-28 09:10 UTC, Peter De Wachter
Details
bugdoc converted to DOC with Word (83.00 KB, application/msword)
2013-03-01 18:25 UTC, Michael Stahl (allotropia)
Details
3.6.7: normal loading (58.49 KB, image/png)
2013-11-16 07:59 UTC, tommy27
Details
4.1.3: bug on loading (26.27 KB, image/png)
2013-11-16 08:00 UTC, tommy27
Details
In the multipage document containing the table pages with continuation of the table are lost. (31.03 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2016-03-16 06:40 UTC, Viktor
Details
Text frame to be split. (12.64 KB, application/vnd.oasis.opendocument.text)
2023-02-06 08:18 UTC, Miklos Vajna
Details
Original bugdoc, re-saved in Word 2021 (35.43 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2023-02-17 15:53 UTC, Miklos Vajna
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Peter De Wachter 2013-02-28 09:10:54 UTC
Created attachment 75671 [details]
Test document

Problem description: 

Steps to reproduce:
1. Open the attached Word document.



Current behavior:

LibreOffice shows single-page document with the beginning of the table.
Also, the title is displayed to the right of the table instead of at the top of the page.

Expected behavior:

LibreOffice shows the table spread out over multiple pages.
              
Operating System: Debian
Version: 4.0.1.2 rc
Last worked in: 3.5.4 release
Comment 1 Peter De Wachter 2013-02-28 09:12:13 UTC Comment hidden (obsolete)
Comment 2 Michael Stahl (allotropia) 2013-03-01 15:04:01 UTC
worked in 3.6.5.2, regression from:

commit edc4861a68e0269b83b17e0ec57912a1ce4220ad
Author: Miklos Vajna <vmiklos@suse.cz>
Date:   Wed Aug 15 16:31:51 2012 +0200

    n#775899 initial docx import of w:vertAnchor inside w:tblpPr
    
which turns the 6 page table into a frame.
Comment 3 Michael Stahl (allotropia) 2013-03-01 15:28:29 UTC
the document contains this:

  <w:tblpPr w:leftFromText="180" w:rightFromText="180" w:vertAnchor="page" w:horzAnchor="margin" w:tblpY="3286"/>

which makes it a "floating table".

unfortunately Writer doesn't support splitting frames across pages,
so the result of importing the multi-page table into a frame is quite horrible.
Comment 4 Michael Stahl (allotropia) 2013-03-01 18:25:29 UTC
Created attachment 75748 [details]
bugdoc converted to DOC with Word

so it appears the WW8 import does exactly the same thing as the
DOCX import now after the change, and has been for a long time
(OOo 3.0.1 also converts the table into a single-page frame).
Comment 5 Miklos Vajna 2013-03-04 08:41:55 UTC
Right, multi-page floating tables never worked, so this is an enhancement request, IIUC. Support for that in Writer core would be indeed nice.
Comment 6 Peter De Wachter 2013-03-04 13:14:02 UTC
Would it be possible for LibreOffice to construct a series of linked frames in this situation? Spanning a table over multiple pages using linked frames is something that LibreOffice can already do.
Comment 7 Miklos Vajna 2013-03-04 17:24:49 UTC
Yes, but those frames are not flying ones. Additionally, the importer has no idea if the table will fit one page or not, so I see no easy way to just ignore the "positioned" property of multi-page tables.
Comment 8 Commit Notification 2013-05-13 09:46:52 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8fe8bd6c3b5b1a539b7370f8c457fa69c061d2de

Related: fdo#61594 SwWW8ImplReader::StartApo: don't always start a frame



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 9 Miklos Vajna 2013-05-13 09:48:05 UTC
To avoid confusion, the above does not fix the problem triggered by the bugdoc, only the case when the table has with >= text area width.
Comment 10 Mikeyy - L10n HR 2013-10-13 14:46:53 UTC
Is Bug 53816 same problem as here?
I reported it some time ago, 1 table (2 columns) spreading over 108 pages, only 3 pages load.

Time needed to load those 3 pages is 22 sec for LO to start and then 1min 48sec to load it fully (total of 2min 10sec).

Tested again with 4.1.3 RC1 and it's not getting better. :)
Comment 11 Thomas van der Meulen [retired] 2013-11-15 17:07:48 UTC
Is this bug maybe related to bug 71584 because that one seems to be fixed since 4.1.3.1 but not in 4.2 alpha 1 and master? any idea
Comment 12 tommy27 2013-11-16 07:59:43 UTC
Created attachment 89303 [details]
3.6.7: normal loading
Comment 13 tommy27 2013-11-16 08:00:20 UTC
Created attachment 89304 [details]
4.1.3: bug on loading
Comment 14 tommy27 2013-11-16 08:03:39 UTC
(In reply to comment #11)
> Is this bug maybe related to bug 71584 because that one seems to be fixed
> since 4.1.3.1 but not in 4.2 alpha 1 and master? any idea

probably related bugs but not the same bug.

bug 71584 is indeed fixed in 4.1.3 while current bug 61594 is still present in that version (see screenshots)

interestingly both bugs are present in 4.2 alpha
so the 4.1.x fix of 71584 did not stick in 4.2.x

I change platform to ALL since I reproduce the bug with Win7 64bit as well
Comment 15 Michael Stahl (allotropia) 2014-01-15 21:30:27 UTC
*** Bug 71584 has been marked as a duplicate of this bug. ***
Comment 16 Matthew Francis 2015-01-25 15:57:05 UTC
Adjusting metadata to indicate that a specific commit has been identified

Adding:
Whiteboard -> bibisected
Keywords -> bisected
Comment 17 Björn Michaelsen 2015-01-27 23:04:09 UTC
As per comment 3/4 this doesnt fit the current document model of Writer, thus its an enhancement. Also it never did fit the document model of Writer before, thus its _not_ a regression. If a document was rendered pleasantly previously by chance that is still not a regression.
Comment 18 Matthew Francis 2015-04-10 11:15:48 UTC
A couple of semi-duplicates of this:

bug 34911
bug 59650

were originally opened for other issues which have been solved. (I closed them after finding that the floating frame import issue was all that remained)
Comment 19 Timur 2015-05-19 11:09:42 UTC Comment hidden (obsolete)
Comment 20 Justin L 2015-07-02 13:06:17 UTC
A workaround from the MS Office side:  Table Properties - set Text Wrapping to None.

Likely there is no reason for text wrapping to be enabled in the document, so by removing these unnecessary settings the document will be compatible with both programs.
Comment 21 Viktor 2016-03-16 06:40:24 UTC
Created attachment 123617 [details]
In the multipage document containing the table pages with continuation of the table are lost.

The document opened:
1) Correctly in Word 2007 and Writer 3.6.7.2
2) Incorrectly in Writer 4.3.7.2, 4.4.7.2, 5.0.4.2 and 5.0.5.2
Windows 7 32bit operating system.
Comment 22 Xisco Faulí 2016-09-26 16:41:00 UTC
*** Bug 94951 has been marked as a duplicate of this bug. ***
Comment 23 Xisco Faulí 2016-09-26 16:41:19 UTC Comment hidden (obsolete)
Comment 24 Xisco Faulí 2016-09-26 16:49:33 UTC Comment hidden (obsolete)
Comment 25 Timur 2016-09-29 15:15:22 UTC
Removing "regression" per Comment 17.
I guess this is the same issue as with attachment 120809 [details] wrongly added to Bug 74915. It's shown in attachment 120810 [details].
Comment 26 Maris Nartiss 2016-10-10 15:14:19 UTC
A partial workaround if re-saving in MSO is not an option:
1) Click in a single cell of table;
2) Hit Ctrl+a twice (it will select whole table but not the outer frame);
3) Ctrl+c followed by ctrl+v outside of original table;
4) Delete original frame with all of its content (click on the outer line/border of table to access it).
Comment 27 Justin L 2016-11-16 13:59:22 UTC
*** Bug 60342 has been marked as a duplicate of this bug. ***
Comment 28 Justin L 2016-11-16 15:03:40 UTC
*** Bug 74915 has been marked as a duplicate of this bug. ***
Comment 29 Xisco Faulí 2018-01-25 11:48:12 UTC
*** Bug 112544 has been marked as a duplicate of this bug. ***
Comment 30 Timur 2018-10-09 10:38:55 UTC
*** Bug 116096 has been marked as a duplicate of this bug. ***
Comment 31 Timur 2018-10-09 10:44:30 UTC
Another example attachment 140231 [details] from 116096. attachment 140282 [details] is comparison LibreOffice 6.1 and MSO 2010. attachment 145515 [details] is source docx saved in MSO with Table Wrap set as None.
Comment 32 Timur 2019-02-11 15:37:25 UTC
*** Bug 112004 has been marked as a duplicate of this bug. ***
Comment 33 Justin L 2020-03-12 07:26:01 UTC
For the brilliant person who implements multipage floating tables, please note Microsoft's compatibility flag "allowTextAfterFloatingTableBreak" - just in case this isn't complex enough...
Comment 35 dm 2022-07-29 10:54:23 UTC
Version: 7.0.3.1
Build ID: d7547858d014d4cf69878db179d326fc3483e082
CPU threads: 2; OS: Linux 5.18; UI render: default; VCL: gtk3
Locale: en-IE (en_US.UTF-8); UI: en-US
Calc: threaded

Version: 7.3.5.2 / LibreOffice Community
Build ID: 184fe81b8c8c30d8b5082578aee2fed2ea847c01
CPU threads: 2; OS: Linux 5.18; UI render: default; VCL: gtk3
Locale: en-IE (en_US.UTF-8); UI: en-US
Calc: threaded

Load the Test Document in reference (longtable.docx)
Click on right border of table (second or subsequent rows)
A blue box appears at the top right corner "Un-float Table"
Click on the box
Nothing happens with version 7.3.x while 7.0.x "unfolds" the table into multiple pages.

In another docx document I was sent with a table similar to that in the "Test Document" (cannot reproduce because I don't have MS Windows / MS Word and cannot attach due to privacy issues) the 7.0.x version rendered the table without the "Un-float" action, while the 7.3.x version did not and, again, did nothing with the "Un-float" action.

This should be considered a regression and the 7.0.x handling re-instated.
Comment 36 dm 2022-07-29 10:56:27 UTC
As a workaround, the table can be selected from the top (selection of columns) and then copy/pasted elsewhere.
Comment 37 Miklos Vajna 2023-02-06 08:18:22 UTC
Created attachment 185144 [details]
Text frame to be split.

I started looking at this. Don't expect fast progress, it's a very complex problem.

I've attached a document which has a text frame that doesn't fit the body frame of the single page.

The first step (I think) is to get this to split to 2 pages. Once that works, it can be improved to also work with content which is not only 2 paragraphs but also an actual table.

Commits like core.git 8855813f8147f430348a32703b89dfb7b0793fee (sw: avoid unwanted initial content in split/follow fly frames, 2023-02-03) are moving towards this direction. You need to opt in for this new code with 'SW_FORCE_FLY_SPLIT=1 soffice' for now.
Comment 38 Miklos Vajna 2023-02-17 15:53:21 UTC
Created attachment 185444 [details]
Original bugdoc, re-saved in Word 2021

Turns out that the original bugdoc behaves a bit weird even in Word, sometimes the content overlaps with the footer for reasons that are not clear to me.

I re-saved the file in Word 2021, allowing it to "upgrade" the document and now at least some of the weird behavior is gone.

So it probably makes sense to focus on this upgraded version first, the compat mode will come later.

As an aside, once you set SW_FORCE_FLY_SPLIT=1, core.git sw/qa/core/layout/data/floattable.docx and sw/qa/core/layout/data/floattable-vertoffset.docx is rendered now so, there is some basic support to split a floating table to 2 pages.
Comment 39 Miklos Vajna 2023-02-28 15:51:47 UTC
Split rows now work. This is needed, but now enough to layout out the above document.
Comment 40 Miklos Vajna 2023-03-10 13:50:31 UTC
With:
 913b71dbe06c33773c4d779e00c6ec4b6a4af59f (sw floattable: ignore height of masters in lcl_CalcMinRowHeight(), 2023-03-10)

now core.git master can lay out orig-nocompat.docx correctly (I think) with SW_FORCE_FLY_SPLIT=1.

The original document has an implicit compat flag to lay it out like Word 2010, that still needs more work, because Word >= 2013 does things differently.
Comment 41 Miklos Vajna 2023-03-17 08:45:26 UTC
After 90523e10ec053347719309403a4d8566da1dfc4a (sw floattable, legacy: also consier fly position when deciding the bottom, 2023-03-17), the same is true for the original document.

Now to enable this by default...
Comment 42 davent 2023-04-02 09:45:26 UTC
@Miklos: Thanks for working on this! I would like to pay you the 100$ from bountysource: https://app.bountysource.com/issues/11638215-fileopen-docx-with-multi-page-floating-table-workaround-from-ms-office-table-properties-set-text-wrapping-to-none 
Can you request the money there?
Comment 43 Commit Notification 2023-04-12 07:12:30 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/ce3308a926f036b87515b8cd97d2b197063dc77a

tdf#61594 sw floattable: import floating tables as split flys by default

It will be available in 7.6.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 44 Miklos Vajna 2023-04-13 11:19:52 UTC
(In reply to davent from comment #42)
> @Miklos: Thanks for working on this! I would like to pay you the 100$ from
> bountysource:
> https://app.bountysource.com/issues/11638215-fileopen-docx-with-multi-page-
> floating-table-workaround-from-ms-office-table-properties-set-text-wrapping-
> to-none 
> Can you request the money there?

Appreciated, but I would suggest to donate it to TDF instead. And be aware that the cost of adding this feature (this bug is just for DOCX import) is in the Eur 100k’s – but TDF will appreciate your donation no doubt.
Comment 45 Stéphane Guillou (stragu) 2023-04-26 16:42:34 UTC
*** Bug 155027 has been marked as a duplicate of this bug. ***
Comment 46 Gabor Kelemen (allotropia) 2023-04-27 11:27:06 UTC
*** Bug 144976 has been marked as a duplicate of this bug. ***
Comment 47 Gabor Kelemen (allotropia) 2023-05-10 12:09:05 UTC
*** Bug 151517 has been marked as a duplicate of this bug. ***
Comment 48 Gabor Kelemen (allotropia) 2023-05-10 12:09:10 UTC
*** Bug 148034 has been marked as a duplicate of this bug. ***
Comment 49 davent 2023-05-15 19:12:35 UTC
(In reply to Miklos Vajna from comment #44)
> (In reply to davent from comment #42)
> > @Miklos: Thanks for working on this! I would like to pay you the 100$ from
> > bountysource:
> > https://app.bountysource.com/issues/11638215-fileopen-docx-with-multi-page-
> > floating-table-workaround-from-ms-office-table-properties-set-text-wrapping-
> > to-none 
> > Can you request the money there?
> 
> Appreciated, but I would suggest to donate it to TDF instead. And be aware
> that the cost of adding this feature (this bug is just for DOCX import) is
> in the Eur 100k’s – but TDF will appreciate your donation no doubt.

I know, I know... but I'm the only backer for this bug on bountysource and I don't know how to get the 100$ back from this strange website. Next time I will donate directly to TDF.
Comment 50 Justin L 2023-05-19 12:00:57 UTC
*** Bug 143729 has been marked as a duplicate of this bug. ***
Comment 51 Justin L 2023-05-19 12:02:36 UTC
*** Bug 143743 has been marked as a duplicate of this bug. ***
Comment 52 Timur 2023-08-28 21:07:29 UTC
*** Bug 156957 has been marked as a duplicate of this bug. ***
Comment 53 Miklos Vajna 2023-10-12 06:36:15 UTC
(In reply to Justin L from comment #33)
> note Microsoft's compatibility flag "allowTextAfterFloatingTableBreak" -
> just in case this isn't complex enough...

https://gerrit.libreoffice.org/c/core/+/157855 starts adding an AllowTextAfterFloatingTableBreak compat flag on our side to do this. See bug 157119 comment 27 and later.