Bug 80717 - FILEOPEN: DOC DOCX file has incorrect vertical position relative to 'page' of floating table
Summary: FILEOPEN: DOC DOCX file has incorrect vertical position relative to 'page' of...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.2.5.2 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA interoperability WW8
Keywords: bibisected, bisected, filter:doc, implementationError
: 94950 94955 129359 (view as bug list)
Depends on:
Blocks: DOC-Tables DOCX-Floatingtable
  Show dependency treegraph
 
Reported: 2014-06-30 15:14 UTC by Marc PHILIPPE
Modified: 2021-03-31 06:45 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments
Original DOC file, resulting ODT, screenshots (568.00 KB, application/zip)
2014-06-30 15:14 UTC, Marc PHILIPPE
Details
Original DOC file, without protection (128.00 KB, application/msword)
2018-11-08 16:17 UTC, Luke
Details
DOC compared MSO LO 4.2 LO 6.2+ (168.42 KB, image/jpeg)
2018-11-09 09:51 UTC, Timur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marc PHILIPPE 2014-06-30 15:14:58 UTC
Created attachment 102018 [details]
Original DOC file, resulting ODT, screenshots

Problem description:
When importing the attached DOC file attached, the gap between the 3rd and the 4th row of the table is not respected.
In the original DOC, the gap is 5 mm high.
In the imported ODT, the gap is 5 cm high.

Steps to reproduce:
1. Open the attached DOC.

Current behavior:
The gap is 5 cm high.

Expected behavior:
The gap height should be the same as in the original DOC file.

(Previously commented in bug 80635.)
Operating System: Windows 7
Version: 4.1.5.3 release
Comment 1 Yousuf Philips (jay) (retired) 2014-06-30 18:04:40 UTC
Confirmed on Linux Mint in 4.1.6 and 4.3.0. In 4.1, the space between tables shrinks, while in 4.2 and above it expands. The second table is in the correct position in 4.0.6, but the first table isnt present.

This issue maybe the byproduct of the tables going over the page width mentioned in bug 80635.
Comment 2 Michael Stahl (allotropia) 2014-07-10 22:08:45 UTC
the spacing is tiny since the de-floating of the table with
commit 8fe8bd6c3b5b1a539b7370f8c457fa69c061d2de

the 5 cm gap comes from:

commit 9d981abc3f310adf9af3454dd515ea356b31d3c1
Author:     Miklos Vajna <vmiklos@collabora.co.uk>
AuthorDate: Mon May 26 12:04:39 2014 +0200

    bnc#863018 WW8 import: fix upper margin of multi-page floating table
Comment 3 Björn Michaelsen 2014-10-16 14:59:05 UTC Comment hidden (obsolete)
Comment 4 Xisco Faulí 2015-09-09 09:38:03 UTC
This issue is still present in

Version: 5.0.1.2
Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261
Locale: es-ES (es_ES)

on Windows 7 (64-bit)
Comment 5 Robinson Tryon (qubit) 2015-12-14 05:19:47 UTC Comment hidden (obsolete)
Comment 6 Björn Michaelsen 2016-08-14 18:47:18 UTC Comment hidden (obsolete)
Comment 7 Timur 2016-08-17 13:27:07 UTC Comment hidden (obsolete)
Comment 8 Yousuf Philips (jay) (retired) 2016-08-24 12:53:41 UTC
Returning to NEW as Michael's bibisect in bug 80635 is different than his bibisect here.
Comment 9 Xisco Faulí 2016-09-26 09:26:15 UTC Comment hidden (obsolete)
Comment 10 QA Administrators 2018-10-02 02:55:18 UTC Comment hidden (obsolete)
Comment 11 Luke 2018-11-08 16:17:03 UTC
Created attachment 146446 [details]
Original DOC file, without protection

In Version: 6.2.0.0.alpha1+ (x64)
Build ID: 4201779de7441c03fbf0fea665d17ed2328970cc

There is still no gap between the 3rd and 4th row.
Comment 12 Timur 2018-11-09 09:51:12 UTC
Created attachment 146486 [details]
DOC compared MSO LO 4.2 LO 6.2+

Floating tables - wrap around. 
1st table: vertical 0,01 cm relative to paragraph, move with text, same position as in MSO
2nd table: vertical 5,26 cm relative to page, position not same as in MSO
Comment 13 Luke 2018-11-09 18:29:34 UTC
I created a stripped down version for testing: attachment 146504 [details]

I also, spun off the 2 page import issue into Bug 121318
Comment 14 Luke 2018-11-09 18:36:04 UTC
The .docx format is also affected by this bug. You can verify this with attachment 146507 [details], a stripped down version of the bugdoc saved as .docx in Word 2016.
Comment 15 QA Administrators 2019-11-10 03:49:03 UTC Comment hidden (obsolete, spam)
Comment 16 Justin L 2020-03-24 11:22:59 UTC Comment hidden (obsolete)
Comment 17 Justin L 2020-03-25 08:20:39 UTC Comment hidden (obsolete)
Comment 18 Justin L 2020-03-26 12:11:04 UTC
Fixing this will take a lot of wizardry, to identify the location on the page where the table is in-lined, and then calculate how much margin to add to the top to push it down to the correct position.  Similar feats are needed especially for left, but also for right.

Then the same can be done for left/right for paragraph-anchored tables, as well as column-anchored tables.

A nice try at wizardry was comment 2's commit at https://gerrit.libreoffice.org/c/core/+/9487/2/sw/source/filter/ww8/ww8par6.cxx
However, it did not account for the current, inlined position and so was reverted... 

Identifying the current position is approximately impossible, since that depends on the layout - which of course we do not have during import.
Comment 19 Justin L 2020-03-28 07:41:39 UTC
*** Bug 94950 has been marked as a duplicate of this bug. ***
Comment 20 Justin L 2020-03-28 07:42:05 UTC
*** Bug 94955 has been marked as a duplicate of this bug. ***
Comment 21 Miklos Vajna 2020-03-30 08:14:12 UTC
> Identifying the current position is approximately impossible, since that depends on the layout - which of course we do not have during import.

We already have bug 61594 for the case where floating tables can't be tweaked import-time and true layout support is needed, should we close this as a duplicate, then?
Comment 22 Justin L 2020-03-30 08:18:39 UTC
(In reply to Miklos Vajna from comment #21)
> We already have bug 61594 for the case where floating tables can't be
> tweaked import-time and true layout support is needed, should we close this
> as a duplicate, then?
I don't think we should mark it as a duplicate of that one.
That one is specifically talking about tables that should or should not be floated. This bug report is talking about tables that HAVE ALREADY been inlined, but where the table isn't vertically positioned correctly.  I guess you could argue that in these cases it shouldn't be inlined then.  But that will be a very subjective call based on each individual document's characteristics.
Comment 23 Miklos Vajna 2020-03-30 08:33:25 UTC
Hmm right. But then this is not a regression, rather a missing functionality. Adjusting keywords accordingly. In any case, thanks for looking into this!
Comment 24 Justin L 2020-04-23 13:23:26 UTC
*** Bug 129359 has been marked as a duplicate of this bug. ***