Download it now!
Bug 135578 - ODT images anchored 'to page', on round trip to OOXML are anchored 'to character' and can't be moved freely
Summary: ODT images anchored 'to page', on round trip to OOXML are anchored 'to charac...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.0.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: filter:ooxml filter:docx
Keywords: bibisectRequest, regression
Depends on:
Blocks: Anchor-and-Text-Wrap
  Show dependency treegraph
 
Reported: 2020-08-09 10:41 UTC by Telesto
Modified: 2020-08-17 17:55 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file (677.81 KB, application/vnd.oasis.opendocument.text)
2020-08-09 10:41 UTC, Telesto
Details
jumping_toCharacter.odt: minimized reproducer, one image, one long paragraph. (683.25 KB, application/vnd.oasis.opendocument.text)
2020-08-11 13:22 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-08-09 10:41:41 UTC
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
Comment 1 Telesto 2020-08-09 10:41:56 UTC
Created attachment 164068 [details]
Example file
Comment 2 Telesto 2020-08-09 10:45:46 UTC
Also found in 6.0

It's surely better in 5.2 (but still bit eccentric)
Comment 3 Telesto 2020-08-09 10:47:33 UTC
Working as expected in

LibreOffice 3.5.7.2 
Build ID: 3215f89-f603614-ab984f2-7348103-1225a5
Comment 4 Telesto 2020-08-09 10:49:33 UTC
@Justin
If you like more of such lovely broken anchoring behavior regressed over the years
Comment 5 V Stuart Foote 2020-08-09 14:23:57 UTC
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.
Comment 6 Telesto 2020-08-09 18:04:34 UTC
Behavior is pretty similar to bug 135576. Adding to See also
Comment 7 Justin L 2020-08-10 06:59:58 UTC
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.
Comment 8 Telesto 2020-08-10 08:10:31 UTC
(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
Comment 9 V Stuart Foote 2020-08-10 13:19:36 UTC
(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.
Comment 10 Justin L 2020-08-11 13:22:11 UTC
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.
Comment 11 Justin L 2020-08-11 13:25:49 UTC
(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.
Comment 12 Telesto 2020-08-11 14:00:41 UTC
(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