Bug 137548 - FILEOPEN Table in compat14 DOCX/DOC should split full row, not move to next page (compat15 is OK)
Summary: FILEOPEN Table in compat14 DOCX/DOC should split full row, not move to next p...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: All All
: low normal
Assignee: Not Assigned
URL:
Whiteboard: compatibilityMode14
Keywords: bibisected, filter:docx, regression
Depends on:
Blocks: DOCX-Tables DOCX-compatibilityMode-15
  Show dependency treegraph
 
Reported: 2020-10-17 04:54 UTC by Aron Budea
Modified: 2022-12-24 03:25 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Sample DOCX (21.08 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-10-17 04:54 UTC, Aron Budea
Details
Screenshot in Writer (94.17 KB, image/png)
2020-10-17 04:54 UTC, Aron Budea
Details
PDF exported from Word (29.16 KB, application/pdf)
2020-10-17 04:56 UTC, Aron Budea
Details
Sample compared in MSO and LO as 2007 DOCX, new DOCX, DOC (88.04 KB, image/png)
2020-10-21 07:44 UTC, Timur
Details
Sample DOCX 2007 resaved in MSO as new DOCX (25.38 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-10-21 07:45 UTC, Timur
Details
Sample DOCX 2007 resaved in MSO as DOC (40.00 KB, application/msword)
2020-10-21 07:45 UTC, Timur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Aron Budea 2020-10-17 04:54:20 UTC
Created attachment 166451 [details]
Sample DOCX

Open the attached DOCX with a table in Writer.

=> The long cell that has "Test" in it is moved to the next page.

The issue seems to depend both on the Heading line in the cell and the length of the cell. If the heading is removed or the table gets shorter, the table remains in one piece.

Observed in LO 7.1.0.0.alpha0+ (f21f3d094cfb495c89dfb0a23ecb061ef1a2178e), 4.4.0.3 / Ubuntu.
Fine in 3.6.0.4.
=> regression

Bibisected to the following range using repo bibisect-43all.
https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=179a6db61ee30cf776747802f06edeef45fec461..5f91f8a368343d8921a01edb7359cd300892f09d
Comment 1 Aron Budea 2020-10-17 04:54:57 UTC
Created attachment 166452 [details]
Screenshot in Writer
Comment 2 Aron Budea 2020-10-17 04:56:09 UTC
Created attachment 166453 [details]
PDF exported from Word
Comment 3 Timur 2020-10-21 07:44:33 UTC
Created attachment 166568 [details]
Sample compared in MSO and LO as 2007 DOCX, new DOCX, DOC

Not a straightforward bug. 
While report is literally true, this is 2007 DOCX.
If resaved and reeopen in MSO, it's different, like in LO. 
I usually close such bugs as "NotOurBug" with the explanation that it's not realistic for LO to emulate different MSO behavior.
Comment 4 Timur 2020-10-21 07:45:13 UTC
Created attachment 166569 [details]
Sample DOCX 2007 resaved in MSO as new DOCX
Comment 5 Timur 2020-10-21 07:45:57 UTC
Created attachment 166570 [details]
Sample DOCX 2007 resaved in MSO as DOC

I'd rather convert this bug to DOC because LO should open it as MSO.
Comment 6 Justin L 2020-12-23 09:00:09 UTC
(The term "heading" is a bit misleading since the table doesn't have any "header rows". So it is a "human" heading only.)

Technically this is a Word 2010 format document.  If Word 2016 resaves it "in compatibility mode" then it continues (in Word) to split the tall row.  When Word 2016 saves it in native compat15 mode, then the full-of-content-cell moves to the next page.

Starting in LO 7.0, we now export DOCX as compat15 mode - so anything LO authors should look proper in non-obsolete MS Word.

This is strictly a layout issue. If we add in the support for DOC, we might as well add in support for compat14 DOCX as well. The question is whether it is worth the effort to add more complexity to the layout - and what other side issues this would trigger. [At this point, I would consider it a WONTFIX, at least as a volunteer.]
See related bug 123116 and bug 105478 for code pointers (and warnings).
Comment 7 QA Administrators 2022-12-24 03:25:27 UTC Comment hidden (spam)