Bug 104876 - docx autosize table created very large - extends way past right margin
Summary: docx autosize table created very large - extends way past right margin
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4.0.3 release
Hardware: All All
: medium normal
Assignee: Justin L
URL:
Whiteboard: target:5.4.0 target:5.3.0.2 target:5.2.5
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2016-12-23 09:23 UTC by Justin L
Modified: 2017-05-18 16:32 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
sw/qa/extras/ooxmlexport/data/hidemark.docx (12.52 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2016-12-23 09:23 UTC, Justin L
Details
hidemark_lo54alpha.pdf: shows why this bug report was created (6.31 KB, application/pdf)
2016-12-23 09:27 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Justin L 2016-12-23 09:23:27 UTC
Created attachment 129890 [details]
sw/qa/extras/ooxmlexport/data/hidemark.docx

This unit test from bnc#865381 should be a tiny 2*2 table.  Instead, the first column fills more than the entire page, and the second *column* is not even seen. (The second *row* is auto-hidden, just so you know.)  Note that the table starts with a left spacing of -0.21 cm.

bibisect-44max points to commit cbd0fbc287051f918e4adb32b3e9b58dfbf8059d
    Author: Miklos Vajna <vmiklos@collabora.co.uk>
    CommitDate: Thu Nov 6 15:56:27 2014 +0100
DOCX import: fix <w:tblW w:type="auto"/> handling when cells have fixed widths
        Commit 74c5ed19f430327988194cdcd6bdff09591a93fa (DOCX import fix for
        table with auto size, 2013-06-26) correctly recognized that in case the
        width type is auto, that doesn't always mean text::SizeType::VARIABLE.
    
        However, when the size is fixed, then we should simply not do anything,
        and that'll lead to the right behavior (by setting the column separators
        on each row), don't try to be smart and try to set
        TablePropertyMap::TABLE_WIDTH here.

tested on: Ubuntu 16.04 x64bit. LO5.4alpha.  
Probably not related to bug 99616 and the hidden rows. The description is similar to bug 99440, except that one is inherited from OOo.
Comment 1 Justin L 2016-12-23 09:27:47 UTC
Created attachment 129891 [details]
hidemark_lo54alpha.pdf: shows why this bug report was created
Comment 2 Xisco Faulí 2016-12-23 12:11:31 UTC
Moving it to NEW as the problematic commit has been identified.

Adding Cc: to Miklos Vajna
Comment 3 Justin L 2016-12-23 15:12:36 UTC
proposing https://gerrit.libreoffice.org/32385 tdf#104876 writerfilter: m_bTableSizeTypeInserted = false here

This is a partial fix which ought to undo the regression.

However, the table width is still wrong - it seems to be twice as wide as it should be.  I'm guessing that hidemark.docx was a hand-crafted txt document, so perhaps there are some content errors. However, that still suggests some kind of bug in handling the specification of 4 grids, but only two non-spanning cells.
Comment 4 Justin L 2016-12-23 19:07:03 UTC
If word2013 round-trips hidemark.docx, then we only get two gridCols instead of 4.  <w:tblGrid><w:gridCol w:w="960"/><w:gridCol w:w="960"/></w:tblGrid>

So it seems to be a consistency problem with the document itself. I'll just ignore that part of the problem since it isn't a completely valid document.
Comment 5 Commit Notification 2017-01-02 07:50:02 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=e73c961a7fb23246dc4a9c27d7ed0808b9ba74b5

tdf#104876 writerfilter: m_bTableSizeTypeInserted = false here

It will be available in 5.4.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 6 Commit Notification 2017-01-02 15:20:35 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "libreoffice-5-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=91867c343d858e7365c06f2953e979bc038af186&h=libreoffice-5-3

tdf#104876 writerfilter: m_bTableSizeTypeInserted = false here

It will be available in 5.3.0.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 7 Commit Notification 2017-01-02 16:22:35 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=bed818c5d5e92a0b189f25e18495fc205d949128&h=libreoffice-5-2

tdf#104876 writerfilter: m_bTableSizeTypeInserted = false here

It will be available in 5.2.5.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 8 vihsa 2017-03-21 08:35:19 UTC
verified.
version: 5.4.0.0.alpha0+ / build id: febc116 / ls-4001 / android 5.1

the first column does not fill entire page & displays two columns.