Bug 105373 - FILEOPEN: Broken view of docx with images and floating table
Summary: FILEOPEN: Broken view of docx with images and floating table
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3 all versions
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:docx
Depends on:
Blocks: DOCX
  Show dependency treegraph
 
Reported: 2017-01-16 19:35 UTC by Peter
Modified: 2019-11-24 13:37 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
The original docx (167.59 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2017-01-16 19:35 UTC, Peter
Details
expected output (177.92 KB, application/vnd.oasis.opendocument.text)
2017-01-16 19:36 UTC, Peter
Details
bug.docx: word 2007 generated file. Replaces original because we have a PDF and it looks good in Word. (53.54 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2017-01-19 05:47 UTC, Justin L
Details
bug2.pdf: pdf from word2007 showing the expected output (182.64 KB, application/pdf)
2017-01-19 05:52 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Peter 2017-01-16 19:35:27 UTC
Created attachment 130480 [details]
The original docx

I have not search if this is a duplicate but as this is not fixed over the last years I thought I send you the document where I observe this broken view.

It is just the header where we have an image (church), then the text and then another image (mouse). And writer opens the image and text on each other
Comment 1 Peter 2017-01-16 19:36:24 UTC
Created attachment 130481 [details]
expected output

Here is the roughly expected output of the document as ODT
Comment 2 Xisco Faulí 2017-01-16 19:55:28 UTC
Confirmed in

Version: 5.4.0.0.alpha0+
Build ID: 36afb355ac37122d32d624db079def123ef548a2
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group

and

Version: 4.2.0.0.alpha1+
Build ID: fc8f44e82de4ebdd50ac5fbb9207cd1a59a927e3

LibreOffice crashes in previous versions...
Comment 3 Xisco Faulí 2017-01-16 20:12:24 UTC
Hi Justin,
I thought you might be interested in this one...
Comment 4 Justin L 2017-01-17 06:26:32 UTC
I'm not sure which is the "original" because the .docx looks poor in MSOffice also.

In looking at the ODT, the design of this document needs to be redone from scratch. It is a complete mess. The heading section has an unnecessary textbox containing an unnecessary table. The first table column is tiny and empty. The other table column has a right-indent of over 3 inches which pushes the text in funny ways when there isn't enough space for the text and the indent. The single-line paragraph properties have negative first-line indents of several inches, as well as nearly reciprocal positive before-text indents of several inches.

This might be a good "compatibility testing" document (there are a ton of bugs in here) but it isn't good for focusing on anything in particular. The interaction of frames and tables and pictures is a deadly combination. I don't see any point in looking at this one until the known issues with picture placement are resolved.

I sent Peter a cleaned up version of the ODT that exports identically in DOCX.
Comment 5 Timur 2017-01-17 08:59:39 UTC
(In reply to Peter from comment #0)
> I have not search if this is a duplicate ...
...which is not correct. 

(In reply to Xisco Faulí from comment #3)
Problems with rendering in files like this one can be obvious, but please do not confirm without search for already reported bugs. 
> Hi Justin,
> I thought you might be interested in this one...
Justin is doing such a great work here, but he should not be called for bugs not properly triaged and seached for duplicates. 


(In reply to Justin L from comment #4)
> I'm not sure which is the "original" because the .docx looks poor in
> MSOffice also.
Triaging not done properly. Developer doing this is a waste of resources. 

> This might be a good "compatibility testing" document (there are a ton of
> bugs in here) but it isn't good for focusing on anything in particular. The
> interaction of frames and tables and pictures is a deadly combination. I
> don't see any point in looking at this one until the known issues with
> picture placement are resolved.
It's all about triaging and checking existing bugs.
Comment 6 Justin L 2017-01-19 05:47:19 UTC
Created attachment 130544 [details]
bug.docx: word 2007 generated file. Replaces original because we have a PDF and it looks good in Word.

OP is receiving .docx files from a colleague, so those are the true source documents. Since he doesn't have Word, he needs to open them with LO.

The top portion of the document is what the complaint is about, and this version of the document contains the same complicated mess of table, textbox, picture anchors, paragraph indents as the original submission.
Comment 7 Justin L 2017-01-19 05:52:13 UTC
Created attachment 130545 [details]
bug2.pdf: pdf from word2007 showing the expected output

OP was given this PDF by his colleague along with the .docx.

P.S. The "roughly expected output" in comment 1 has the picture order reversed. The mouse should be on the left, and the church on the right.
Comment 8 QA Administrators 2018-03-15 03:38:24 UTC Comment hidden (obsolete)
Comment 9 Roman Kuznetsov 2018-11-23 08:33:10 UTC
still repro in

Version: 6.2.0.0.beta1
Build ID: d1b41307be3f8c19fe6f1938cf056e7ff1eb1d18
CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; 
Locale: ru-RU (ru_RU); UI-Language: en-US
Calc: threaded
Comment 10 QA Administrators 2019-11-24 03:36:54 UTC Comment hidden (obsolete)
Comment 11 Peter 2019-11-24 13:37:12 UTC
As this document seems to be a mess it should be redone and so this can be closed as "won't fix" :)

Still this is not fixed in Version: 6.0.7.3 and Justin said

> This might be a good "compatibility testing" document 

so this could be kept open too. Some developer needs to decide.