Description: Image anchored to page can't be moved freely after DOCX export Steps to Reproduce: 1. open the attached file 2. Save as DOCX 3. File reload 4. Select the image at the right bottom & try to drag around Actual Results: Image doesn't respond or strangly Expected Results: Normal Reproducible: Always User Profile Reset: No Additional Info: Found in Version: 7.1.0.0.alpha0+ (x64) Build ID: <buildversion> CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: ru-RU (nl_NL); UI: en-US Calc: CL not in 4.4.7.2
Created attachment 164068 [details] Example file
Also found in 6.0 It's surely better in 5.2 (but still bit eccentric)
Working as expected in LibreOffice 3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5
@Justin If you like more of such lovely broken anchoring behavior regressed over the years
Confirmed on Version: 7.0.0.3 (x64) Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded No issue *without* the round trip to OOXML. An anchoring issue for the frame holding the image--coming back in set 'as character'. So is this the ww8 export filter, or the ww8 import filter? Looking at the LO exported OOXML archive. The images *are* anchored wp:anchor to document 0,0 and assigned an wp:posOffset x,y offset. So guess that means the change is from the import filter.
Behavior is pretty similar to bug 135576. Adding to See also
I'm seeing them in DOCX as "to-character", not "as-character". (So the subject should be changed. Was that a typing mistake?) Contrary to OP, I ALWAYS see the image responding somehow to a drag-and-drop. But when you let go, it doesn't stay in the position that you dropped it, and the positioning seems to be very erratic and inconsistent. So it is completely impossible to position the image where you want it. If the first image is deleted, or anchored somewhere other than position 0, or anchored to-paragraph, then positioning the second image is no longer erratic.
(In reply to Justin L from comment #7) > I'm seeing them in DOCX as "to-character", not "as-character". (So the > subject should be changed. Was that a typing mistake?) > > Contrary to OP, I ALWAYS see the image responding somehow to a drag-and-drop. > But when you let go, it doesn't stay in the position that you dropped it, > and the positioning seems to be very erratic and inconsistent. So it is > completely impossible to position the image where you want it. > > If the first image is deleted, or anchored somewhere other than position 0, > or anchored to-paragraph, then positioning the second image is no longer > erratic. Me being slightly sloppy with description. What you described is the problem. Instead of dragging you could also use the arrow keys.. which don't respond I'm not sure if this is a DOCX problem specific, something old. It's surely not unique. Except it did work in previous versions. As said see also.. which again has an additional example going back to 3.3.0
(In reply to Justin L from comment #7) > I'm seeing them in DOCX as "to-character", not "as-character". (So the > subject should be changed. Was that a typing mistake?) > Oh, sorry Justin, looked again at the OOXML .DOCX filter imported to LibreOffice Writer. On "round-trip" the image anchors change: from 'To Page' to 'To Character' Looking at the Anchor attribute for the images I mis-read/typed them 'as character'. BZ Summary is correc now.
Created attachment 164160 [details] jumping_toCharacter.odt: minimized reproducer, one image, one long paragraph. (In reply to Telesto from comment #8) > I'm not sure if this is a DOCX problem specific, something old. No, it wouldn't be a docx problem. Just a to-character problem. In this reduced example, I noticed that when it is anchored on the first page, it behaves well. But when anchored on the second page, it goes berserk (going back to at least LO 3.5 - as far back I can bibisect using 16.04). I also notice that the anchor always SEEMS to move to the zero position on the paragraph or page while you are dragging - which is confusing/annoying - and then jumps back when you drop. If there IS no paragraph start on the page, that is when the picture placement goes wonky.
(In reply to Justin L from comment #10) > If there IS no paragraph start on the > page, that is when the picture placement goes wonky. This is similar to "to-paragraph" anchoring, except that the image cannot move to a different page. But the location of the file at the bottom of the page kindof mirrors what is seen for to-character drag-drops where the picture likes the hug the bottom of the page.
(In reply to Justin L from comment #11) Not sure if you're will work on this or not.. but just in case: be aware of/ include bug 133970
I don't find a "to page" anchoring in Word; also I can't find a related markup in ECMA-376. Is there such a feature in OOXML actually? IMO "images anchored 'to page', on round trip to OOXML are anchored 'to character'" part is NOTABUG, since if there's no support for a feature in an external format, we can't roundtrip it.
(In reply to Mike Kaganski from comment #13) > I don't find a "to page" anchoring in Word; also I can't find a related > markup in ECMA-376. Is there such a feature in OOXML actually? > > IMO "images anchored 'to page', on round trip to OOXML are anchored 'to > character'" part is NOTABUG, since if there's no support for a feature in an > external format, we can't roundtrip it. There are a million open bug reports about to-character anchored images. So lets close this one that wants an impossible situation.
*** This bug has been marked as a duplicate of bug 37002 ***