Bug 104596 - FILEOPEN: green image in .DOC header incorrectly positioned, "bellow paragraph" from Word not correctly set "from top to margin" in Writer
Summary: FILEOPEN: green image in .DOC header incorrectly positioned, "bellow paragrap...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Justin L
Whiteboard: target:7.1.0
Keywords: bibisected, filter:doc, regression
Depends on:
Blocks: DOC-Images DOC-Header-Footer
  Show dependency treegraph
Reported: 2016-12-12 08:06 UTC by Ilario Gottardello
Modified: 2020-07-20 10:11 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

File that shows the problem (301.23 KB, application/x-7z-compressed)
2016-12-12 08:06 UTC, Ilario Gottardello
How it should be (46.83 KB, image/png)
2016-12-12 08:39 UTC, Ilario Gottardello
How is rendered (28.72 KB, image/png)
2016-12-12 08:39 UTC, Ilario Gottardello
tdf104596_breakingExample.odt: old ODT documents will be changed. (57.39 KB, application/vnd.oasis.opendocument.text)
2020-04-16 14:18 UTC, Justin L
tdf104596_breakingExampleB.odt: more likely scenarios in this one. (62.86 KB, application/vnd.oasis.opendocument.text)
2020-04-18 07:06 UTC, Justin L
tdf104596_tableAnchorInFootnote.docx: issue also applies to footnotes (22.07 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-06-25 12:18 UTC, Justin L

Note You need to log in before you can comment on or make changes to this bug.
Description Ilario Gottardello 2016-12-12 08:06:42 UTC
Created attachment 129512 [details]
File that shows the problem

Opening Office files gives an image positioned not correctly: the position of the green image is wrong and text goes above it.
Comment 1 tommy27 2016-12-12 08:26:29 UTC Comment hidden (obsolete)
Comment 2 Ilario Gottardello 2016-12-12 08:39:30 UTC
Created attachment 129517 [details]
How it should be
Comment 3 Ilario Gottardello 2016-12-12 08:39:52 UTC
Created attachment 129518 [details]
How is rendered
Comment 4 Ilario Gottardello 2016-12-12 08:44:04 UTC Comment hidden (obsolete)
Comment 5 tommy27 2016-12-12 13:36:47 UTC
bug confirmed under Win7 x64 using LibO and (x64)
Build ID: 7aa2b5a041df8e71a435cccbc79ee13799ec9138
CPU Threads: 8; OS Version: Windows 6.1; UI Render: default; Layout Engine: new; 
TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2016-11-24_11:40:27
Locale: it-IT (it_IT); Calc: CL

status NEW
Comment 6 Terrence Enger 2016-12-14 22:28:02 UTC
I also see the green images above the table on Linux, specifically in
the daily Linux dbgutil bibisect repository version 2016-12-14 running
on debian-stretch 64-bit.
Comment 7 Ilario Gottardello 2017-12-12 12:46:46 UTC
Bug still present in beta:

Build ID: 13edaaa12f25de343fce136064e27da66c1c4fa4
CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: kde4; 
Locale: it-IT (it_IT.UTF-8); Calc: group threaded
Comment 8 Timur 2018-02-20 12:38:52 UTC
Repro in 6.1+.
Vertical position in Word is absolute -0,66 cm bellow paragraph. 
Vertical position in Writer is from top by -0,66 cm to margin. 
Looks like it was correctly positioned up to LO 4.0.5 with 0 to margin, so I'll mark as regression.
Comment 9 Buovjaga 2018-07-05 12:06:12 UTC Comment hidden (obsolete)
Comment 10 Buovjaga 2018-07-05 15:31:20 UTC
Bibisected on Linux with 43all to range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=d74ba0c4147f33abd9d0c03883cc88f15e160ee5...358b60b3b172968a7605b428af01df456d7669b2

The range is a bit wide as I had to skip a couple of commits due to this:
/home/test/bibisect-43all/opt/program/../ure-link/bin/javaldx: error while loading shared libraries: libjvmfwk.so.3: cannot open shared object file: No such file or directory
Warning: failed to read path from javaldx
/home/test/bibisect-43all/opt/program/soffice.bin: error while loading shared libraries: libreg.so.3: cannot open shared object file: No such file or directory

I was unable to find a guilty commit. I even tried a build after removing this commit as it sounded suspicious, but it did not help: https://cgit.freedesktop.org/libreoffice/core/commit/?id=4e07258cbd1f4fb16d6ce2174fb5c74c3b36da33
Comment 11 Timur 2018-12-27 17:11:19 UTC Comment hidden (obsolete)
Comment 12 Justin L 2020-04-16 12:25:00 UTC
Repro 7.0+
The green box is now inside of the table, but the text is not wrapping around it.

There seems to be some kind of layout exception for wrapping in headers for MS compatibility (see commits for bug 39155 - which I found using bibisect 43all - looking for the last time text would wrap in the header, which was LO 3.6).


Lots of old commits trying to figure this out. Here is an interesting one:
commit 70b4ac2416f65437c8553d2e69f6920ce26d4fd8
Author: Jens-Heiner Rechtien <hr@openoffice.org>
Date:   Mon Feb 2 17:35:49 2004 +0000
+    // OD 14.10.2003 - keep wrapping of objects in page header/footer.
+    /*
     //#108778# when in a header or footer word appears to treat all elements
     //are wrap through
     if (bIsHeader || bIsFooter)
         pF->nwr = 3;
+    */


This particular document has a few other complicating factors.
The first is that there is a continuous section break. The first section has a wrap-through green square, and the second section has a no-wrap green-square. Word 2016 kindof falls over with this document.
Even Word 2003, when you look at the properties of section 1's green square and then hit OK - the green square merges with the text - just like LO shows it. So there is some kind of corruption or invalidity in this.
Comment 13 Justin L 2020-04-16 12:39:12 UTC
(In reply to Justin L from comment #12)
> This particular document has a few other complicating factors.
Cancel this entire statement. I must have resaved with LO at some point.
Comment 14 Justin L 2020-04-16 14:15:25 UTC
proposed fix at http://gerrit.libreoffice.org/c/core/+/92378
Comment 15 Justin L 2020-04-16 14:18:59 UTC
Created attachment 159634 [details]
tdf104596_breakingExample.odt: old ODT documents will be changed.

My fix affects layout in general, so that will impact everything. I have attached an example document which I think fairly clearly shows that it really shouldn't be problematic because it is easy to fix (just wrap through in the foreground) and rarely would someone intentionally make this kind of document anyway.
Comment 16 Justin L 2020-04-18 07:06:21 UTC
Created attachment 159671 [details]
tdf104596_breakingExampleB.odt: more likely scenarios in this one.

A clue in an earlier comment prompted me to "work around" the wrapping problem to create a more realistic header. So yeah, this could break more documents than I originally thought. Still easy to fix, but people (including me) don't want to "fix" previously designed documents.
Comment 17 Justin L 2020-06-25 12:18:18 UTC
Created attachment 162399 [details]
tdf104596_tableAnchorInFootnote.docx: issue also applies to footnotes

In reviewing the code, I noticed that footnotes are also excluded from wrapping, as well as headers/footers. My patch allowed wrapping in both cases, so I this document is a proof that it really is needed for footnotes as well.
Comment 18 Commit Notification 2020-07-17 17:49:26 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":


tdf#104596 sw COMPAT layout: wrap in header for in-table flies

It will be available in 7.1.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:

Affected users are encouraged to test the fix and report feedback.
Comment 19 Xisco Faulí 2020-07-20 10:11:27 UTC
Verified in

Build ID: abea0d6647c7f1f7e76c73c26cb80e6a67dc5111
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

@Justin, thanks for fixing this issue!