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.
thanks for your bug report
please upload a screenshot showing the correct position in MS Word and the wrong position in LibO.
you labeled this as inherited from OOo, that means you tested it woth OOo 3.3.0; please confirm that.
also tell which LibO version you are using and your exact O/S.
set it back to UNCONFIRMED once you reply to those questions.
Created attachment 129517 [details]
How it should be
Created attachment 129518 [details]
How is rendered
Well, I copyed the other bug report I've filed (104431), that was edited by another person.
I am using:
Versione: 220.127.116.11 (x64)
Build ID: d54a8868f08a7b39642414cf2c8ef2f228f780cf
Thread CPU: 4
Versione SO: Windows 6.19
Resa interfaccia: predefinito
Versione locale: it-IT (it_IT)
bug confirmed under Win7 x64 using LibO 18.104.22.168 and 22.214.171.124.alpha0+ (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
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.
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
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.
Still repro, will bibisect later.
Arch Linux 64-bit
Build ID: ea39c41fdf63191579d25f327db81db14862251c
CPU threads: 8; OS: Linux 4.17; UI render: default; VCL: gtk3;
Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded
Built on July 4th 2018
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
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:
Author: Jens-Heiner Rechtien <firstname.lastname@example.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.
(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.
proposed fix at http://gerrit.libreoffice.org/c/core/+/92378
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.
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.
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.
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.
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
@Justin, thanks for fixing this issue!