Bug 59274 - FILEOPEN: table in DOCX file is more narrower than it should be (no AutoFit Table Layout from OOXML)
Summary: FILEOPEN: table in DOCX file is more narrower than it should be (no AutoFit T...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: Other All
: high normal
Assignee: Not Assigned
Whiteboard: interoperability
Keywords: bibisected, filter:docx
: 80286 (view as bug list)
Depends on:
Blocks: DOCX-Tables
  Show dependency treegraph
Reported: 2013-01-12 09:45 UTC by Mateusz
Modified: 2019-06-06 13:13 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:

Table in Writer 4.0.2 (48.59 KB, image/png)
2013-04-03 10:57 UTC, Mateusz
Table in Writer 4.0.3 (27.39 KB, image/png)
2013-04-03 10:57 UTC, Mateusz
Table in Word Viewer (48.89 KB, image/png)
2013-04-03 11:06 UTC, Mateusz
Table compare MSO LO (170.25 KB, image/jpeg)
2016-10-10 10:43 UTC, Timur

Note You need to log in before you can comment on or make changes to this bug.
Description Mateusz 2013-01-12 09:45:00 UTC

For Michael Meeks' request [ https://bugs.freedesktop.org/show_bug.cgi?id=47594#c8 ] I split one big bug for a few smaller. This issue is related with Bug 59273 - FILEOPEN: Writer doesn't display all table cells in DOCX file [ https://bugs.freedesktop.org/show_bug.cgi?id=59273 ]

I don't want upload many times the same files so I will include links from other bugs. 

Fixing this bug shouldn't be hard to do. 

This picture show how it should looks. 

Now, download source file, open it and compare with screenshot
Comment 1 Joel Madero 2013-01-14 17:58:14 UTC
It looks like it was a problem in 3.6 as well. Changing version to to reflect the earliest version that I can confirm the bug on.

Marking as:
New (confirmed)
Normal (can affect high quality work)
High (common feature, if you look at progress over the last couple months on 4.0 you can see a lot of changes to how tables are handled and it's broken in a couple ways). 

Thanks for reporting.
Comment 2 Mateusz 2013-01-22 17:05:55 UTC
I tested daily build from 21.01.13 and bug still exist there. Meanwhile I test it with some master build (LO 4.1) and in this compilation, file has been displayed correctly, such as in Word.
Comment 3 Mateusz 2013-04-03 10:57:11 UTC
Created attachment 77376 [details]
Table in Writer 4.0.2
Comment 4 Mateusz 2013-04-03 10:57:46 UTC
Created attachment 77377 [details]
Table in Writer 4.0.3

@Joel Madero

Can Miklos Vajna take care for this issue? He resolved yesterday similar issue ( fdo#59273 ) but every new change turn out to be annoying regression.

Writer 4.0.2 – correct width of table, but one call was disappear [solved in 4.0.3]
Writer 4.0.3 – all cells are displaying correctly, but whole table is more narrower than it's in reality [regression]
Comment 5 Mateusz 2013-04-03 11:06:15 UTC
Created attachment 77378 [details]
Table in Word Viewer
Comment 6 Miklos Vajna 2013-04-04 05:55:05 UTC
LibreOffice 4.0.3 is to be released in May -- please copy&paste the versions from the about dialog for both the old and the new version, then I can try to see what can I do for you. :-)
Comment 7 Mateusz 2013-04-04 08:04:33 UTC
Wersja (Build ID: 4c82dcdd6efcd48b1d8bba66bfe1989deee49c3

Version (Build ID: fb0cdcb8e3084ac969a8d744e0e55041431b862)
Comment 8 Miklos Vajna 2013-04-04 08:25:46 UTC
Oh, I see, so you mean 4.0.2 vs -4-0 daily build. Then this is caused by 7329df74df134a77d078f47d5c8b70d54c5d1edb, in a good sense.

> Fixing this bug shouldn't be hard to do.

Happy to read that, though I must admit I disagree. As far as I understand it, Word has an auto-layout mode, where it takes the columns widths requested by the file, but if the width is too small and the column has some content, it'll make it larger. This is not defined by the OOXML standard as:

"AutoFit Table Layout - This method of table layout uses the preferred widths on the table items to generate the
final sizing of the table, but then uses the contents of each cell to determine final column widths."

As far as I understand, Writer layout has only support for what OOXML calls "Fixed Width Table Layout", so no, it's not trivial at all to fix this, I'm afraid.

An easy workaround is to just re-save the document using Word, then the weird 1px-column-with-lots-of-contents part of the bugdoc just goes away.
Comment 9 Miklos Vajna 2013-04-04 08:27:00 UTC
> This is not defined by the OOXML standard as:

"this is defined by", of course.
Comment 10 Xisco Faulí 2014-03-31 16:32:59 UTC
This issue is still reproducible with:
   - Libreoffice Build ID: 1c1366bba2ba2b554cd2ca4d87c06da81c05d24
   - Libreoffice Build ID: 3be8cda0bddd8e430d8cda1ebfd581265cca5a0f
   - Libreoffice Build ID: b6a43bcbbf9e9a5655fd36fd4c8ef72d585f67b0
Comment 11 Matthew Francis 2015-04-10 09:19:11 UTC
The rendering of the file seems unchanged since OOo / LO 3.3.0
-> Version: Inherited from OOo
Comment 12 tommy27 2016-04-16 07:27:28 UTC Comment hidden (obsolete)
Comment 13 Xisco Faulí 2016-10-09 20:14:19 UTC Comment hidden (obsolete)
Comment 14 Xisco Faulí 2016-10-09 20:14:37 UTC
*** Bug 80286 has been marked as a duplicate of this bug. ***
Comment 15 Timur 2016-10-10 10:43:40 UTC
Created attachment 127917 [details]
Table compare MSO LO
Comment 16 Timur 2016-10-27 08:26:35 UTC Comment hidden (obsolete)
Comment 17 Cor Nouws 2016-10-27 08:43:01 UTC Comment hidden (obsolete)
Comment 18 QA Administrators 2017-12-08 08:07:10 UTC Comment hidden (obsolete)
Comment 19 Cor Nouws 2017-12-29 11:35:46 UTC Comment hidden (obsolete)
Comment 20 QA Administrators 2018-12-30 03:47:50 UTC Comment hidden (obsolete)
Comment 21 Cor Nouws 2019-01-01 18:16:19 UTC
problem persists in Version:
Build ID: 082144fa0fb2021cfb41494bb6eb5bf417e58ab1
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2018-12-31_03:11:43
Locale: nl-NL (nl_NL.UTF-8); UI-Language: en-US
Calc: threaded

(no idea why this was set bisected / 4.1 > comments show it's inherited from OOo)