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)
Created attachment 156045 [details] Example file from Word
Created attachment 156046 [details] Screenshot of the original document side by side in Word and Writer
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
Also reproduced in Version: 4.3.0.0.alpha1+ Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
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.
Adding CC to: Michael Stahl
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.
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.
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.
Created attachment 157542 [details] Example compared MSO LO Looking better, but still not good, because of spacing.
(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.
Created attachment 157605 [details] unit test document without spacing problem
@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.)
*** Bug 133897 has been marked as a duplicate of this bug. ***
*** Bug 88126 has been marked as a duplicate of this bug. ***
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.
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.