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
Created attachment 172412 [details] Bad render screenshot
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 ***
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.
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.
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.
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.
Created attachment 172494 [details] The minimized example file in Word and Writer
Let me hijack this report :).
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
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.
proposed fix at http://gerrit.libreoffice.org/c/core/+/120275
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.