Created attachment 129689 [details] sample Steps: 1. Open attached document Observed behaviour: There's an extra page at the end of the document Reproduced in Version: 5.4.0.0.alpha0+ Build ID: 634589b340316ba64b731b4d923c1056be415494 CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group
Regression introduced by: author Mike Kaganski <mike.kaganski@collabora.com> 2016-09-08 04:20:18 (GMT) committer Miklos Vajna <vmiklos@collabora.co.uk> 2016-09-08 21:08:56 (GMT) commit ba18832ceeda21f047a664b71a4333a54737e6c8 (patch) tree 22eed6857474964d19ffd5f57e8e2e19dbac3140 parent d45d8ae3c51606eb1d9e63396a0eab13c8742907 (diff) tdf#75221: make margin collapsing implementation conform OASIS proposal Since the margin collapsing (aka contextual spacing, implemented for LO 3.6 by Miklos Vajna, commits 6f04bf5e90ff75288dcf75c43843edf798641e3d, 0662778b0b4b9958ee5e5bd3bac69f9e290f9495, 11059331718fb8faab483c75633b4e80d8028b7d, 03f9b6bebc0ca77021be46664c7bcbe4cb297503, 8631dbf85fb5ed56d225e32ea5a9c36c96b0d649, 9f4bb5bd4f55b4a80544413efde26391849b1d7f, f722299e133568fe75f7cf9ce0c103a1553474c4) is only meant to suppress fo:margin-top and fo:margin-bottom, as seen in https://issues.oasis-open.org/browse/OFFICE-3767, current implementation is inconsistent: it nullifies all spacing, including normal line spacing. Adding Cc: to Mike Kaganski
I suppose that this is the result of rounding error. MS Word has virtually zero space between the last paragraph and margin. LibreOffice exceeds the available body space (that is counted identically to MS Word to be 12960 twips) by 35 twips = 0.617 mm. So, last line cannot fit and is moved to new page. As page layout is measured in integral twips, I suppose, any fractional text height will be rounded up. Possibly that adds up with some yet another rounding error, thus giving this result. The commit above isn't the real cause of the problem, it just corrected improper layout, that happened to reveal this corner case of rounding. Possibly if we used floats for layouting (or some units much smaller than twips), that could be mitigated somehow.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
still repro in Version: 6.1.1.2 (x64) Build ID: 5d19a1bfa650b796764388cd8b33a5af1f5baa1b CPU threads: 4; OS: Windows 10.0; UI render: default; Locale: ru-RU (ru_RU); Calc: CL
I have played a little with the sample from attachment 129689 [details], and I see that the problem is incorrect height of two paragraphs just above "1.0 Research Question" (the latter is imported with incorrect font, either - but that's out of scope here). Simply making the text of these two previously empty paragraphs (modifying the XML) fixes the problem. So - I remove the "regression" decorations from this issue. This has been pre-existing; and only became apparent when the other problem in the same sample (which was incorrect treatment of margin collapsing) was fixed, so that other paragraphs' height became normal.
Created attachment 144980 [details] Sample minimized Title "Extra page added at the end of the document" was misleading because it's a consequence, so I change to "Empty paragraph shows Default style instead of Heading and takes Heading style size 24 instead of formatted size 12". If we change original DOCX in MSO to add something in empty paragraph, it will still show Default instead of Heading in LO, but it will be 12 as expected and not 24. Somewhat minimized sample attached.
Dear Xisco Faulí, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still reproducible in Version: 6.4.0.0.alpha0+ Build ID: 938d304f0f28962594853a8db1cc574abff8dc49 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded
(In reply to Timur from comment #6) > If we change original DOCX in MSO to add something in empty paragraph, it > will still show Default instead of Heading in LO... The style is a CHARACTER style, not a PARAGRAPH style. So no problem here. The problem is that direct sz=12pt/font=Calibri character formatting is not overriding the rStyle=Heading1Char sz=24pt/font=TNR. <w:p> <w:pPr> <w:rPr> <w:rStyle w:val="Heading1Char"/> <w:rFonts w:eastAsia="Calibri"/> <w:sz w:val="24"/> </w:rPr> </w:pPr> </w:p>
*** This bug has been marked as a duplicate of bug 127368 ***