Bug 142542 - FILEOPEN DOCX Extra paragraph spacing in direct formatted text (comment #5)
Summary: FILEOPEN DOCX Extra paragraph spacing in direct formatted text (comment #5)
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.2.0.4 release
Hardware: All All
: medium normal
Assignee: Justin L
URL:
Whiteboard: target:7.3.0
Keywords: bibisected, bisected
Depends on:
Blocks: DOCX-Paragraph
  Show dependency treegraph
 
Reported: 2021-05-28 14:35 UTC by Banibrata Dutta
Modified: 2021-11-05 19:46 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Bad render screenshot (16.99 KB, image/png)
2021-05-28 14:35 UTC, Banibrata Dutta
Details
MSWord doc sample that renders badly (38.54 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2021-05-31 10:01 UTC, Banibrata Dutta
Details
The example file in Word 2019 and current nightly (151.78 KB, image/png)
2021-05-31 12:18 UTC, NISZ LibreOffice Team
Details
Minimized example file (22.69 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2021-05-31 12:29 UTC, NISZ LibreOffice Team
Details
The minimized example file in Word and Writer (140.17 KB, image/png)
2021-05-31 12:29 UTC, NISZ LibreOffice Team
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Banibrata Dutta 2021-05-28 14:35:10 UTC
Description:
MSWord (2016) document with an anchored table (see image) renders incorrectly. The table starts near the bottom of the page, visually overlaid over the footer, and the part that should actually be visible in next page, is simply invisible. The next/caption for the table, does render right distance away indicating the it's placement is correct.

This is a proprietary doc so unable to share the doc. 

Steps to Reproduce:
1.Have an anchored table (as shown in screenshot) placed near bottom of page, with content that is sure to overflow onto next page, in a document saved as Word 2013-16 doc.
2.
3.

Actual Results:
Improper rendering, and not as expected.

Expected Results:
Rendering in a way that the table and it's contents do not:
1. Render over the footer region
2. Render visibly into next page, having gracefully flowed-out to next page.
3. On initial page only that much content should render, that fits into the remaining area (within margins and excluding footer area) of the page.


Reproducible: Always


User Profile Reset: No



Additional Info:
[Information automatically included from LibreOffice]
Locale: en-US
Module: TextDocument
[Information guessed from browser]
OS: Linux (All)
OS is 64bit: yes

Screenshot: https://imgur.com/LAONKCU
Comment 1 Banibrata Dutta 2021-05-28 14:35:46 UTC
Created attachment 172412 [details]
Bad render screenshot
Comment 2 NISZ LibreOffice Team 2021-05-31 09:11:00 UTC
That does not look like a table, more like a textbox. Which would make this a duplicate of bug #138282

If you cannot share the file or at least the page with this textbox (even with all characters replaced in Word to an x) then we go with this option.

*** This bug has been marked as a duplicate of bug 138282 ***
Comment 3 Timur 2021-05-31 09:30:51 UTC
Please read https://wiki.documentfoundation.org/QA/BugReport.
Sample is necessary, minimal is preferred, without personal info.
If original is DOC/X from MSO, it must be reduced there, not in LO.
Comment 4 Banibrata Dutta 2021-05-31 10:01:10 UTC
Created attachment 172480 [details]
MSWord doc sample that renders badly

Note that I've stripped-out and obfuscated text in the hope of retaining the issue. There is one single comment in the document, for the element where I found rendering to be an issue.
Comment 5 NISZ LibreOffice Team 2021-05-31 12:18:15 UTC
Created attachment 172492 [details]
The example file in Word 2019 and current nightly

Thanks for the example file, I think the problem with the textbox is indeed the same as the duplicate bug.

However, this file also falls apart because of the paragraph spacing: for some reason there is 0.49 cm before and after on the paragraphs with "Automatic" value and that's way more than it seems to be in Word.

This happens in:
Version: 7.2.0.0.alpha1+ (x64) / LibreOffice Community
Build ID: 187136265d26c014e842550c2f1fc5997736e4fa
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: default; VCL: win
Locale: hu-HU (hu_HU); UI: en-US
Calc: CL

And all the way back to 4.2, but not yet in 4.1. So this seems like an interesting regression on its own.
Comment 6 NISZ LibreOffice Team 2021-05-31 12:29:30 UTC
Created attachment 172493 [details]
Minimized example file

Reduced to only a few paragraphs that have a bit of direct formatting and nothing much else. These appeared without extra before-after spacing in 4.1 but with that in 4.2.

Also the text in the table only has extra After paragraph spacing unlike the others, so this may be a bit different issue, but keeping it here anyways.
Comment 7 NISZ LibreOffice Team 2021-05-31 12:29:59 UTC
Created attachment 172494 [details]
The minimized example file in Word and Writer
Comment 8 NISZ LibreOffice Team 2021-05-31 12:31:40 UTC
Let me hijack this report :).
Comment 9 Timur 2021-05-31 13:18:09 UTC
42max points to Bug 95031:
commit 4a7f49cda4c413431e49f25a18a11fbae12d2651
Date:   Sat Sep 5 20:38:51 2015 +0800
    source-hash-279ff2e03371542d014bf281e73282ba8080cf6b
    previous source-hash-774a202ed5ae22ccff9baccdee5f440ab0774571
    Author:     Miklos Vajna <vmiklos@suse.cz>
    AuthorDate: Wed Aug 28 11:24:07 2013 +0200
        bnc#816593 DOCX import: fix auto para spacing without compat option
Comment 10 Justin L 2021-08-04 18:11:57 UTC
This is not really a regression. It just exposes more clearly an existing failure.

The "Normal" style turns on autospacing. What LO shows is what it would loook like with this autospacing enabled. However, the individual paragraphs turn it off with direct formatting. The problem is that (probably for the sake of not spamming settings) this 0 value is ignored in finishParagraph because bIsZeroAutospacingWithoutTopmargin.

So we need to also check that the style is not setting autospacing before deciding not to write anything.
Comment 11 Justin L 2021-08-10 15:04:31 UTC
proposed fix at http://gerrit.libreoffice.org/c/core/+/120275
Comment 12 Commit Notification 2021-08-20 15:12:56 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/f4b80f4e060a68aa35a7ec678d18af989e82f055

tdf#142542 writerfilter: allow para to cancel style autoSpacing

It will be available in 7.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.