Bug 127368 - FILEOPEN DOCX character properties cannot be applied to only the paragraph marker CR (see comment 6)
Summary: FILEOPEN DOCX character properties cannot be applied to only the paragraph ma...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
: 70007 73238 104496 104712 117988 (view as bug list)
Depends on:
Blocks: DOCX-Paragraph
  Show dependency treegraph
Reported: 2019-09-05 11:06 UTC by NISZ LibreOffice Team
Modified: 2023-12-04 20:08 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:

Distance problem in LO 6.4 (161.68 KB, image/png)
2019-09-05 11:08 UTC, NISZ LibreOffice Team
Example file from Word (35.88 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2019-09-05 11:08 UTC, NISZ LibreOffice Team
distance-between-lines_tdf127368C.docx: edited by word2003 - should be five pages (31.17 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2019-09-24 09:48 UTC, Justin L

Note You need to log in before you can comment on or make changes to this bug.
Description NISZ LibreOffice Team 2019-09-05 11:06:55 UTC
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
Comment 1 NISZ LibreOffice Team 2019-09-05 11:08:39 UTC
Created attachment 153911 [details]
Distance problem in LO 6.4
Comment 2 NISZ LibreOffice Team 2019-09-05 11:08:55 UTC
Created attachment 153912 [details]
Example file from Word
Comment 3 NISZ LibreOffice Team 2019-09-05 11:09:10 UTC
Adding CC to: Justin Luth
Comment 4 Durgapriyanka 2019-09-05 15:53:44 UTC
Thank you for reporting the bug.

I can reproduce the bug in

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-
Comment 5 Dieter 2019-09-06 06:22:37 UTC
Status NEW because of comment 4.
Comment 6 Justin L 2019-09-24 09:48:30 UTC
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.
Comment 7 Justin L 2019-09-24 16:32:45 UTC
From OPs example, the paragraph fallback size should be 11pt.
    <w:sz w:val="22"/>
Comment 8 Justin L 2019-09-25 07:32:44 UTC
*** Bug 117988 has been marked as a duplicate of this bug. ***
Comment 9 Justin L 2019-09-25 07:36:41 UTC
*** Bug 70007 has been marked as a duplicate of this bug. ***
Comment 10 Michael Stahl (allotropia) 2019-09-25 10:40:21 UTC
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.
Comment 11 Justin L 2019-10-30 10:51:43 UTC
*** Bug 73238 has been marked as a duplicate of this bug. ***
Comment 12 Justin L 2020-03-07 18:52:45 UTC
*** Bug 104712 has been marked as a duplicate of this bug. ***
Comment 13 Justin L 2020-03-12 07:00:45 UTC
*** Bug 104496 has been marked as a duplicate of this bug. ***
Comment 14 QA Administrators 2022-08-29 06:43:48 UTC Comment hidden (obsolete)
Comment 15 Gabor Kelemen (allotropia) 2022-08-29 09:56:09 UTC
Original document was fixed in 6.4 with 


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.
Comment 16 Justin L 2023-05-18 13:11:59 UTC
repro 7.6+