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
(corrected version number)
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.
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.
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).
Right, multi-page floating tables never worked, so this is an enhancement request, IIUC. Support for that in Writer core would be indeed nice.
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.
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.
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.
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.
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. :)
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
Created attachment 89303 [details] 3.6.7: normal loading
Created attachment 89304 [details] 4.1.3: bug on loading
(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
*** Bug 71584 has been marked as a duplicate of this bug. ***
Adjusting metadata to indicate that a specific commit has been identified Adding: Whiteboard -> bibisected Keywords -> bisected
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.
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)
Added bisected Bug 82553 to See also, possible duplicate.
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.
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.
*** Bug 94951 has been marked as a duplicate of this bug. ***
*** Bug 79329 has been marked as a duplicate of this bug. ***
Adding Cc: to Miklos Vajna
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].
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).
*** Bug 60342 has been marked as a duplicate of this bug. ***
*** Bug 74915 has been marked as a duplicate of this bug. ***
*** Bug 112544 has been marked as a duplicate of this bug. ***
*** Bug 116096 has been marked as a duplicate of this bug. ***
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.
*** Bug 112004 has been marked as a duplicate of this bug. ***