Description: Docx file contains a table starting in page 1 and goes up to the page 2. The table has total 22 rows. LO renders 20 rows on 1st page and 2 rows on second page. where as MS word renders 21 rows on 1st page and 1 row on the second page. Steps to Reproduce: 1.Open the attached "Table_Rows_Rendering_Issue_Lo.docx" in both LO and MS word. 2.See the number of rows rendered in 1st page and second page between two applications. Actual Results: The number of rows that renders on page 1 and page 2 are differs when compared to MS word. Expected Results: LO should render same as MS word. Reproducible: Always User Profile Reset: Yes Additional Info: Attachments:"Table_Rows_Rendering_Issue_Lo.docx" and "Table_Rows_Rendering_Issue_Lo.png"
Created attachment 187883 [details] Table_Rows_Rendering_Issue_Lo.docx
Created attachment 187884 [details] Table_Rows_Rendering_Issue_Lo.png
Just L, This happens mostly when we have header and footer, looks like some spacing calculation or height calculation when we have header and footer. Do you have any idea on this ?
(In reply to SATYA SRINIVAS K from comment #3) > looks like some height calculation when we have header and footer. I know that there is not a lot of 1 to 1 mapping in the header/footer configurations - a lot is just emulation, trying to get the two to look similar. MS Word has no concept of page styles, while LO puts everything header/footer related into a page style. So there are all kinds of incompatible results in this area. Likely there is no "correct" answer here, and it would take a lot of effort to learn the specific quirks in each system in order to propose a better "emulation". (see bug 70195, bug 146347, bug 137111 and bug 131531) However, I don't think that is the problem in this case. I did a PDF comparison of MSO 2010 and LO 24.2. The biggest vertical difference seems to be the last bullet point "String" in row 2. There is direct pargraph formatting "spacing after/below" of 10pt/.35cm/.64 line. This is being ignored by MS Word (I assume because of "don't add space between paragraphs of the same style" and the fact that there is no paragraph after this one.
Created attachment 187906 [details] Table_Rows_Rendering_Issue_MIN.docx: 1 page table with "Don't add space between paragraphs of the same style"
(In reply to Justin L from comment #5) > Created attachment 187906 [details] > Table_Rows_Rendering_Issue_MIN.docx: 1 page table with "Don't add space > between paragraphs of the same style" I will check and ignore adding the space between paragraphs of the same style, Can you point out some code locations to start with it ?
(In reply to SATYA SRINIVAS K from comment #6) > Can you point out some code locations to start with it Follow the trail of See Also bug(s). Specifically https://gerrit.libreoffice.org/c/core/+/28692 which has links to the initial implementation of the entire feature in LO 3.6.
The problem with this document ("Table_Rows_Rendering_Issue_MIN.docx") is started appearing after this commit. https://git.libreoffice.org/core/+/b271cc46851c61ddef20dc869bf339c857f76b18%5E%21/
Before the above mentioned commit, "Table_Rows_Rendering_Issue_MIN.docx" is working as same as MSO but the other document "Table_Rows_Rendering_Issue_Lo.docx" still has the same problem mentioned in the issue, maybe the root cause for these two documents are different ?
Created attachment 188053 [details] Line spacing issue
There is a extra lower space in a cell which causes the shifting of rows to the next page if the table has more rows.As a test if I return 0 lower space from SwFlowFrame::CalcLowerSpace method, it is working fine with the larger table. (see attached "line_spacing_issue.png")
It has nothing to do with "Don't add space between paragraphs of the same style" feature. Unchecking this in Word makes no difference on whether it adds the space in the bottom of the cell. The more important is how this space below is handled at the bottom of the page. Test this: create several 1-line paragraphs, and set all of them to have large (say, 2 cm) spacing below - to make sure that more than 1 page is needed. Check how the bottommost paragraph on the first page is rendered; playing with the spacing, you may see that the spacing is ignored at the bottom, so that the paragraph is shown, even when the spacing below doesn't fit. This behavior is the same in Word and in Writer. But Word seems to treat cells the same way (which seems reasonable), while in Writer, it is added in cells.
I'm sorry - I likely messed with my testing. Re-tested now with a clean Word document, and indeed, the "Don't add space between paragraphs of the same style" makes the difference there. Disregard my previous comment.
You may be interested in SwFlowFrame::CalcAddLowerSpaceAsLastInTableCell function.
(In reply to Mike Kaganski from comment #14) > You may be interested in SwFlowFrame::CalcAddLowerSpaceAsLastInTableCell > function. Yes, this condition in the above function if (rIDSA.get(DocumentSettingId::ADD_PARA_LINE_SPACING_TO_TABLE_CELLS)) { nAdditionalLowerSpace += _pAttrs->CalcLineSpacing(); } adding a line spacing to nAdditionalLowerSpace when I bypass this adding line space my scenario is working fine, but how to decide when to skip this condition.
(In reply to SATYA SRINIVAS K from comment #15) > Yes, this condition in the above function > if (rIDSA.get(DocumentSettingId::ADD_PARA_LINE_SPACING_TO_TABLE_CELLS)) > { > nAdditionalLowerSpace += _pAttrs->CalcLineSpacing(); > } > adding a line spacing to nAdditionalLowerSpace when I bypass this adding > line space my scenario is working fine You might want to check if the "Don't add space between paragraphs of the same style" applies to what CalcLineSpacing calculates, or maybe to another value. > but how to decide when to skip this condition. You might want to re-read comment 7, follow its link, and read the changed code, to see what and when is used/skipped.
Existing unit tests that have conditional spacing at the end of the cell -tdf150443.docx: interesting test. The first cell has upper spacing, but none of the rest of the cells do (because it is a different paragraph style than the last style before the table). The last column controls whether lower spacing is added, contrary to this bug report. Probably the reason is because it is not using the normal paragraph style. -tdf97090.docx: vertically centred "Издания Echoes:" in single cell/paragraph table. Neither upper nor lower spacing is applied - but the text is vertically centred in the row/table of a specified size (so it APPEARS as if it is applied). -n780853.docx: first cell conditional, second cell isn't. First cell is "Date" paragraph style, while preceding/following cells are not, so spacing needs to apply. -tdf123705.docx: a "list paragraph" bullet point during LAYOUT at end of page triggered the code. This is not the situation we are trying to address (although in that case the spacing isn't added anyway...) So, based on these observations, that adds a huge wrinkle to the problem. At the end of the cell, we need to know -is this really the end of the cell, or just the bottom of the page. -is there another column? Does it start with the same paragraph style? -is this the last column? (In this case, it appears as if MS Word treats the "following style" as the default style.)
Created attachment 188078 [details] 155813_ConditionalSpacingInTables.docx: demonstration of MSO logic
Created attachment 188079 [details] 155813_ConditionalSpacingInTables_MSO2010.pdf: how it looks in Word 2010
More existing unit tests: -forum-mso-en-13192-min.docx // another good example -floattable-table-row-keep.docx: another LAYOUT with list paragraph example -floattable-next-leaf-in-section.docx: another LAYOUT list para example -tdf147199.docx: another LAYOUT list para example
Created attachment 188443 [details] 155813_ConditionalSpacingInTables2.docx: a minimal example
Created attachment 188444 [details] 155813_ConditionalSpacingInTables2_mso2010.pdf