Bug 128959 - FILEOPEN DOCX Table row content disappears when broken between pages
Summary: FILEOPEN DOCX Table row content disappears when broken between pages
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: Not Assigned
URL:
Whiteboard: target:6.5.0
Keywords: filter:docx
: 133897 (view as bug list)
Depends on:
Blocks: DOCX-Tables
  Show dependency treegraph
 
Reported: 2019-11-22 12:28 UTC by NISZ LibreOffice Team
Modified: 2021-01-25 08:12 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file from Word (27.63 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2019-11-22 12:29 UTC, NISZ LibreOffice Team
Details
Screenshot of the original document side by side in Word and Writer (110.09 KB, image/png)
2019-11-22 12:30 UTC, NISZ LibreOffice Team
Details
Screenshot of the document in Writer 6.3 dev version (88.12 KB, image/png)
2019-12-03 13:23 UTC, NISZ LibreOffice Team
Details
Example compared MSO LO (50.18 KB, image/png)
2020-01-30 16:51 UTC, Timur
Details
unit test document without spacing problem (23.92 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-02-03 07:38 UTC, László Németh
Details
How it looks in current 7.2 master and Word 2013 (154.62 KB, image/png)
2021-01-25 08:12 UTC, NISZ LibreOffice Team
Details

Note You need to log in before you can comment on or make changes to this bug.
Description NISZ LibreOffice Team 2019-11-22 12:28:54 UTC
Description:
Attached document contains a table that has a page broken inside a row. The text is multiple lines long but only the first line is readable in the row containing the page break.

Steps to Reproduce:
1.	Open attached document

Actual Results:
Only the first row of text is visible in the 3 a) paragraph.

Expected Results:
All of the text is visible.


Reproducible: Always


User Profile Reset: No



Additional Info:
LibreOffice details:
Version: 6.5.0.0.alpha0+ (x64)
Build ID: 7e09d08807b5ba2fd8b9831557752a415bdad562
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win; 
Locale: en-US (hu_HU); UI-Language: en-US
Calc: CL

Already happens in:
Verzió: 4.0.0.3 (Build az.: 7545bee9c2a0782548772a21bc84a9dcc583b89)
Comment 1 NISZ LibreOffice Team 2019-11-22 12:29:26 UTC
Created attachment 156045 [details]
Example file from Word
Comment 2 NISZ LibreOffice Team 2019-11-22 12:30:04 UTC
Created attachment 156046 [details]
Screenshot of the original document side by side in Word and Writer
Comment 3 Dieter 2019-11-23 09:53:20 UTC
I confirm it with

Version: 6.4.0.0.beta1 (x64)
Build ID: 4d7e5b0c40ed843384704eca3ce21981d4e98920
CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: GL; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-US
Calc: threaded

in comparison with MS Word 2016
Comment 4 Xisco Faulí 2019-12-02 16:27:16 UTC
Also reproduced in

Version: 4.3.0.0.alpha1+
Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e

Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
Comment 5 NISZ LibreOffice Team 2019-12-03 13:23:36 UTC
Created attachment 156268 [details]
Screenshot of the document in Writer 6.3 dev version

We found that this was working during the 6.3 cycle for a while. Seems that 

https://cgit.freedesktop.org/libreoffice/core/commit/?id=b7d4418c309c8bc4fd25485dd3a0ea6ad9edf34e

fixed this particular case, then 

https://cgit.freedesktop.org/libreoffice/core/commit/?id=1caea03fcc6c24e38b2d1d9f6097ad84183ffefd broke it.

Pictured is the document in bibisect-win32-6.3 running the last commit before 1caea03

The "3 a)" paragraph has 2 lines on the bottom of the first page and 1 line at the top of the second, as expected.
Comment 6 NISZ LibreOffice Team 2019-12-03 13:24:30 UTC
Adding CC to: Michael Stahl
Comment 7 Michael Stahl (allotropia) 2019-12-03 13:29:07 UTC
well the commit b7d4418c309c8bc4fd25485dd3a0ea6ad9edf34e turned out to be wrong, so calling it a regression based on that commit being a "fix" is a bit far fetched.
Comment 8 László Németh 2020-01-29 10:01:22 UTC
tdf#128959 DOCX import: fix missing text lines in tables

Orphan/widow line break settings aren't always ignored
by Writer table layout code, in this case, in vertically
merged cells, resulting missing paragraph lines.

As a workaround for interoperability, disable orphan/widow
control in cell paragraphs during the DOCX import to get
correct layout in Writer, too.
Comment 9 Commit Notification 2020-01-29 10:01:49 UTC
László Németh committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/8b13da71aedd094de0d351a4bd5ad43fdb4bddde

tdf#128959 DOCX import: fix missing text lines in tables

It will be available in 6.5.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 10 Timur 2020-01-30 16:51:00 UTC
Created attachment 157542 [details]
Example compared MSO LO

Looking better, but still not good, because of spacing.
Comment 11 Gabor Kelemen (allotropia) 2020-01-31 17:06:18 UTC
(In reply to Timur from comment #10)
> Created attachment 157542 [details]
> Example compared MSO LO
> 
> Looking better, but still not good, because of spacing.

That's 0.35 cm of "new" Spacing After instead of 0.
Comment 12 László Németh 2020-02-03 07:38:54 UTC
Created attachment 157605 [details]
unit test document without spacing problem
Comment 13 László Németh 2020-02-03 07:53:08 UTC
@Timur, Gábor: It seems, the problem is that the recent table layout code uses loop control in several places to avoid dead lock/freezing, resulting random layout (there was a real freezing in LO 6.1 for these test documents). The remaining spacing problem can be easily resolvable by removing the spacing after setting of the paragraph, but this is not a general solution, only an ad hoc one for an ad hoc problem. I've attached an unit test, when there is no such problem, but the document still contains the same extra spacing after setting, showing that minor differences from MSO's table layout can result such problems easily. I suggest to create a new issue for the remaining very special table layout problems. (It's obvious, that the most important ones are the freezings, I've solved a few ones by loop control, and there is no general solution here to get the same layout as in MSO, unfortunately.)
Comment 14 Timur 2020-09-30 10:44:47 UTC
*** Bug 133897 has been marked as a duplicate of this bug. ***
Comment 15 NISZ LibreOffice Team 2020-10-30 11:01:30 UTC
*** Bug 88126 has been marked as a duplicate of this bug. ***
Comment 16 Dieter 2021-01-25 07:42:11 UTC
VERIFIED with

Version: 7.2.0.0.alpha0+ (x64)
Build ID: 9f9798f07f0b56ae474f31ded671cc8da598d244
CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: threaded

Problem of bug report is resolved. I agree, that we should treat the problem with "Spacing After" as different bug.
Comment 17 NISZ LibreOffice Team 2021-01-25 08:12:20 UTC
Created attachment 169130 [details]
How it looks in current 7.2 master and Word 2013

Looks a lot better now in:

Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 45e8dcec908878c07e3835fde7aa9db754d45ace
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: hu-HU (hu_HU); UI: en-US
Calc: CL

The extra spacing issue seems to have been solved since attachment #157542 [details] was taken.

Now only the text highlighting is a bit funny... but I can live with that.