Bug 115094 - FILEOPEN: DOCX: Image in table is misplaced
Summary: FILEOPEN: DOCX: Image in table is misplaced
Status: ASSIGNED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Patrick Jaap
URL:
Whiteboard:
Keywords: filter:docx
Depends on:
Blocks: DOCX-Tables
  Show dependency treegraph
 
Reported: 2018-01-18 18:00 UTC by Patrick Jaap
Modified: 2018-10-11 10:12 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
test file (14.71 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2018-01-18 18:01 UTC, Patrick Jaap
Details
LO Writer (current master) render (13.25 KB, application/pdf)
2018-01-18 18:01 UTC, Patrick Jaap
Details
MSO 2013 render (107.36 KB, application/pdf)
2018-01-18 18:02 UTC, Patrick Jaap
Details
Another test file (31.43 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2018-04-07 17:37 UTC, Patrick Jaap
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Jaap 2018-01-18 18:00:55 UTC
Description:
This may be related to a lot of other bugs, but I'm not sure.

There is a frame in the test file. Within the frame, there is a table with only one cell. Within this, there is a small image.

(The table is put into a frame, so you can move it around in LO Writer)

Steps to Reproduce:
1. open the test file in Writer

Actual Results:  
The image is outside the frame

Expected Results:
The image should be in the frame (see attached PDF)


Reproducible: Always


User Profile Reset: No



Additional Info:


User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Comment 1 Patrick Jaap 2018-01-18 18:01:22 UTC
Created attachment 139195 [details]
test file
Comment 2 Patrick Jaap 2018-01-18 18:01:49 UTC
Created attachment 139196 [details]
LO Writer (current master) render
Comment 3 Patrick Jaap 2018-01-18 18:02:10 UTC
Created attachment 139197 [details]
MSO 2013 render
Comment 4 Xisco Faulí 2018-01-19 10:44:53 UTC
Confirmed in

Version: 6.1.0.0.alpha0+
Build ID: 226804c8f7d2306562380283edfd919a88863807
CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded

Version: 5.2.0.0.alpha0+
Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53
Threads 4; Ver: 4.10; Render: default; 

Version: 4.3.0.0.alpha1+
Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e

Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)

LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4
Comment 5 Chavdar 2018-01-20 20:09:52 UTC
Confirmed 

Version: 5.4.4.2 (x64)
Build ID: 2524958677847fb3bb44820e40380acbe820f960
CPU threads: 4; OS: Windows 6.19; UI render: default; 
Locale: bg-BG (bg_BG); Calc: group

Version: 6.1.0.0.alpha0+
Build ID: d28e10b095b4ee0986fbe86170928bf077da04b9
CPU threads: 4; OS: Windows 10.0; UI render: default; 
TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2018-01-13_22:59:50
Locale: bg-BG (bg_BG); Calc: group threaded
Comment 6 Patrick Jaap 2018-01-26 18:24:43 UTC
I investigated the problem but I couldn't find it's cause... 

The anchor is set completely wrong. The absolute position "nTopOfAnch" in sw/layout is somewhere at 1700, but it has to be much more in the test file.
The option "layoutInCell" of the docx is somehow recognized because manipulating this value leads to an even worse rendering of the document ...

But then I get lost in the code and I think that some writer expert has to take a deeper look here.
Comment 7 Patrick Jaap 2018-02-26 11:13:24 UTC
Hi! A small update on this bug.

After import, the doc model dump (nodes.xml) indicates that the image is not located within the table at all. It is attached independ of the table at a separate (empty) node (Thanks to Miklos for the hint!). This seems like a reasonable conclusion, since the image is put at the very beginning of the page and it's anchor is somewhere off the page.

But this can be "fixed" by disabling the "SectionPropertyMap::FloatingTableConversion" in PropertyMap.cxx to avoid calling SwXText::convertToTextFrame. Then, the table layout gets lost (that's bad) but the image is put in context of the table in the nodes.xml. Additionally, the image is placed at the right position within the table!

So, import of all components seems right, but the floating talbe conversion breaks the bonding of table and image.
Comment 8 Patrick Jaap 2018-02-28 12:54:25 UTC
Another info:

Disabling/removing line 1689 in sw/core/unocore/unotext.cxx:

-> aAnchor.SetAnchor(aMovePam.Start()); <-

in function SwXText::convertToTextFrame actually leads to a correct result. Then, the old anchor (at node 9) is not overwritten by the new anchor (at node 22). I have no idea where the node 22 comes from.

The content of nodes.xml and the resulting render looks good if the image is anchored at node 9. 

So maybe this info helps for future work on this bug!
Comment 9 Patrick Jaap 2018-04-07 17:37:06 UTC
Created attachment 141194 [details]
Another test file

The second test file contains 2 images. They should be located within the table but appear to be outside