Bug 104712 - FILEOPEN: DOCX: Empty paragraph shows Default style instead of Heading and takes Heading style size 24 instead of formatted size 12
Summary: FILEOPEN: DOCX: Empty paragraph shows Default style instead of Heading and ta...
Status: RESOLVED DUPLICATE of bug 127368
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.3.0.0.alpha0+
Hardware: All All
: lowest minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:docx
Depends on:
Blocks: DOCX
  Show dependency tree / graph
 
Reported: 2016-12-16 11:48 UTC by Xisco Faulí
Modified: 2020-03-07 18:52 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Attachments
sample (46.93 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2016-12-16 11:48 UTC, Xisco Faulí 		Details
Sample minimized (19.96 KB, application/vnd.openxmlformats-officedocument.wordprocessingml)
2018-09-18 10:09 UTC, Timur 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Xisco Faulí 2016-12-16 11:48:37 UTC 
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
Comment 1 Xisco Faulí 2016-12-16 11:50:03 UTC 
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
Comment 2 Mike Kaganski 2016-12-16 15:27:26 UTC 
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.
Comment 3 QA Administrators 2018-09-15 03:09:52 UTC Comment hidden (obsolete)
Comment 4 Roman Kuznetsov 2018-09-15 12:25:42 UTC 
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
Comment 5 Mike Kaganski 2018-09-18 08:24:27 UTC 
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.
Comment 6 Timur 2018-09-18 10:09:51 UTC 
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.
Comment 7 QA Administrators 2019-09-19 03:14:37 UTC Comment hidden (obsolete)
Comment 8 Xisco Faulí 2019-09-19 06:36:53 UTC 
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
Comment 9 Justin L 2019-10-15 09:46:34 UTC 
(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>
Comment 10 Justin L 2020-03-07 18:52:45 UTC 

*** This bug has been marked as a duplicate of bug 127368 ***