Download it now!
Bug 119748 - Pasting image in a DOC(X) document shows it with wrong wrapping
Summary: Pasting image in a DOC(X) document shows it with wrong wrapping
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.0.0
Keywords:
: 123257 (view as bug list)
Depends on:
Blocks: Anchor-and-Text-Wrap Paste DOCX-Images DOC-Images DOCX-Anchor-and-Text-Wrap DOC-Anchor-and-Text-Wrap
  Show dependency treegraph
 
Reported: 2018-09-07 13:41 UTC by Aron Budea
Modified: 2020-09-08 11:20 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample DOCX (5.22 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2018-09-07 13:41 UTC, Aron Budea
Details
Sample DOC (14.50 KB, application/msword)
2018-09-07 13:42 UTC, Aron Budea
Details
Sample ODT (for comparison) (15.97 KB, application/vnd.oasis.opendocument.text)
2018-09-07 13:43 UTC, Aron Budea
Details
Comparison screenshot (DOCX - ODT) (129.02 KB, image/png)
2018-09-07 13:45 UTC, Aron Budea
Details
tdf119748_pasteImage.docx: minor looping example (5.30 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-02-11 10:34 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Aron Budea 2018-09-07 13:41:27 UTC
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.
Comment 1 Aron Budea 2018-09-07 13:42:09 UTC
Created attachment 144736 [details]
Sample DOC
Comment 2 Aron Budea 2018-09-07 13:43:53 UTC
Created attachment 144737 [details]
Sample ODT (for comparison)
Comment 3 Aron Budea 2018-09-07 13:45:24 UTC
Created attachment 144738 [details]
Comparison screenshot (DOCX - ODT)
Comment 4 Dieter 2018-09-07 14:01:50 UTC
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
Comment 5 Justin L 2020-02-05 15:58:13 UTC
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...
Comment 6 Justin L 2020-02-05 18:29:25 UTC
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...
Comment 7 Justin L 2020-02-07 16:26:53 UTC Comment hidden (obsolete)
Comment 8 Justin L 2020-02-11 10:34:16 UTC
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.
Comment 9 Justin L 2020-02-18 06:03:51 UTC
(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.
Comment 10 Commit Notification 2020-03-05 09:02:05 UTC
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.
Comment 11 Jan-Marek Glogowski 2020-03-06 22:18:58 UTC
*** Bug 123257 has been marked as a duplicate of this bug. ***
Comment 12 Jan-Marek Glogowski 2020-03-06 22:28:03 UTC
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.
Comment 13 Justin L 2020-03-07 04:32:45 UTC
Note to self: in case there are any regressions, see https://gerrit.libreoffice.org/c/core/+/90126 as an alternative way of doing it.
Comment 14 Justin L 2020-03-31 13:53:49 UTC
(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...