Description: The horizontal line as used by MS Word worked fine in LO earlier versions but in LO 6.4 the lines distance shrinks. Steps to Reproduce: 1. Create a new docx file in MS Word 2. Insert some horizontal lines, save, close Actual Results: The distance between the lines is much less than it was in Word. Expected Results: The distance between the lines should be the same like in word or the older LO versions. Reproducible: Always User Profile Reset: No Additional Info: Additional Information: Bibisected using bibisect-win32-6.2 to: URL: https://cgit.freedesktop.org/libreoffice/core/commit/?id=49ddaad2f3ba4e17e1e41e94824fb94468d2b680 author: Justin Luth committer: Miklos Vajna summary: tdf#117988 writerfilter: IgnoreTabsAndBlanksForLineCalculation
Created attachment 153911 [details] Distance problem in LO 6.4
Created attachment 153912 [details] Example file from Word
Adding CC to: Justin Luth
Thank you for reporting the bug. I can reproduce the bug in Version: 6.3.0.0.alpha0+ Build ID: b6b28931435e44aca92b8c0e1659f701e3ed1a87 CPU threads: 2; OS: Windows 6.1; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-01-30_06:57:04 Locale: en-US (en_US); UI-Language: en-US Calc: threaded but, not in LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
Status NEW because of comment 4.
Created attachment 154418 [details] distance-between-lines_tdf127368C.docx: edited by word2003 - should be five pages This new example document shows that LO didn't properly evaluate the document prior to LO 6.2. LO basically ignores the size attribute, since it only applies to the CR marker - which LO doesn't support. I changed to a huge font, and set the spacing to single-spacing (instead of 1.5 from the original example), and set the default font to a very small size to emphasize the problem. LO also doesn't have a "horizontal line" equivalent, so it has to emulate that with a shape. Since the shape itself only takes up a small amount of space, the lines are compacted together. The horizontal lines were not visible until LO 6.0. Another simple example document that illustrates the basic problem is attachment 139078 [details] lastEmptyParagraph.odt: save as .docx looses the 96 pt paragraph size I will not be treating this as a regression.
From OPs example, the paragraph fallback size should be 11pt. <w:pPr> <w:rPr> <w:sz w:val="22"/> </w:rPr> </w:pPr>
*** Bug 117988 has been marked as a duplicate of this bug. ***
*** Bug 70007 has been marked as a duplicate of this bug. ***
just noticed this, see also commit 5ba30f588d6e41a13d68b1461345fca7a7ca61ac which added a new item to store this rPr stuff to apply it to list labels; there are some TODOs related to that such as that the empty hint is still inserted because it's required for some test that checks the paragraph height which sounds related to this bug.
*** Bug 73238 has been marked as a duplicate of this bug. ***
*** Bug 104712 has been marked as a duplicate of this bug. ***
*** Bug 104496 has been marked as a duplicate of this bug. ***
Dear NISZ LibreOffice Team, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Original document was fixed in 6.4 with https://git.libreoffice.org/core/+/202bee1a819de7b1e8c75dd863c4154f66419400 Revert "tdf#117988 writerfilter: IgnoreTabsAndBlanksForLineCalculation" comment #6: The second attachment 154418 [details] still looks bad, one page instead of five. The attachment 139078 [details] is still bad upon save as docx and reload in Writer, but not in Word: the size is retained correctly there. Let me change the meta as well, this is bad in a document without shapes.
repro 7.6+