Created attachment 144735 [details] Sample DOCX - Open a DOC(X) file, eg. the attached, very simple documents with only a bit of text. - Copy an image to the clipboard from an external application, eg. take a screenshot. - Paste the image into the text somewhere in the middle of the paragraph. => The image covers the text instead of the default "Optimal Page Wrap", even though the wrapping setting itself is the same. Observed using LO 6.1.0.3 & 3.3.0 (at least with DOC, DOCX seems to behave differently, but still wrong) / Windows 7.
Created attachment 144736 [details] Sample DOC
Created attachment 144737 [details] Sample ODT (for comparison)
Created attachment 144738 [details] Comparison screenshot (DOCX - ODT)
I confirm it with Version: 6.0.6.2 (x64) Build-ID: 0c292870b25a325b5ed35f6b45599d2ea4458e77 CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; Gebietsschema: de-DE (de_DE); Calc: group
This is a layout issue. If you save and reload, the wrapping is seen. This can also affect ODT files. Save the .docx as an ODT and it will be affected. It has to do with compatibility mode CONSIDER_WRAP_ON_OBJECT_POS, specifically SwTextFly::InitAnchoredObjList's call to !pAnchoredObj->ConsiderForTextWrap() Now to figure out how to tell if this came via pasting...
Wrapping also happens if you move or resize the image. So any kind of manipulation will "fix" the problem. Why isn't ADDING the image considered to be manipulation...
WIP patch at https://gerrit.libreoffice.org/c/core/+/88221
Created attachment 157790 [details] tdf119748_pasteImage.docx: minor looping example I noticed that my paste-image solution was causing looping in this "flow to the next page" example. However, unpatched "Insert image" did the same thing. In both cases it doesn't loop forever, so likely one of the layout loops catches it and forces a resolution. I tried to use this as a unit test with the pre-existing libreoffice.png, but ooxmlexport10's paste function didn't work since png has no import filter name. I couldn't find any other examples of testing copy/paste, so I gave up.
(In reply to Justin L from comment #7) > WIP patch at https://gerrit.libreoffice.org/c/core/+/88221 Abandoned. It works as a hack, but not as a proper fix.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1052acae9a599c54e518c8fc17d6a994d8778757 tdf#119748 sw layout: ConsiderTextWrap on initial positioning It will be available in 7.0.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.
*** Bug 123257 has been marked as a duplicate of this bug. ***
I guess the test problem is the result of the turbo handling for fast rendering of the visible page, before the idle renderer kicks in. Maybe it's possible to write a UI test for this? Interestingly my fixes for the Writer Idle layout rendering somehow exposed this bug for the bug document from bug 123257. The only important call is the pFly->SetConsiderForTextWrap(true), so text wrap is actually enabled for the fly.
Note to self: in case there are any regressions, see https://gerrit.libreoffice.org/c/core/+/90126 as an alternative way of doing it.
(In reply to Justin L from comment #13) > Note to self: in case there are any regressions, see > https://gerrit.libreoffice.org/c/core/+/90126 as an alternative way of doing > it. ...and indeed, bug 131707 indicates various regressions, so jmux wins for now...