Bug 81568 - FILEOPEN: DOCX: particular table does not have width
Summary: FILEOPEN: DOCX: particular table does not have width
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4.0.0.alpha0+ Master
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, filter:docx, regression
Depends on:
Blocks: 38066
  Show dependency treegraph
 
Reported: 2014-07-20 17:40 UTC by Jorendc
Modified: 2015-12-17 04:35 UTC (History)
0 users

See Also:
Crash report or crash signature:


Attachments
How it looks in LO4.4 (33.94 KB, image/png)
2014-07-20 17:40 UTC, Jorendc
Details
bibisectlog (2.22 KB, text/plain)
2014-07-22 19:22 UTC, Jorendc
Details
left, original as it now is. Right with patch I mention in comment 5 (58.27 KB, image/png)
2014-07-22 22:19 UTC, Jorendc
Details
How it looks now (281.40 KB, image/png)
2014-09-14 18:48 UTC, Jorendc
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jorendc 2014-07-20 17:40:27 UTC
Created attachment 103149 [details]
How it looks in LO4.4

Found this during testing bug 38066

* Open attachment 47702 [details]

Behavior: only 1 line is shown, which should be a table border. 
attachment 86843 [details] do show the behavior of 4.1.1.2 which is much better related to the table width -> regression

Tested using Windows 8.1 with LibreOffice Version: 4.4.0.0.alpha0+
Build ID: a82ff18269e5b37348d402b7c21c3f200068265c
TinderBox: Win-x86@39, Branch:master, Time: 2014-07-20_02:34:36
Comment 1 Jorendc 2014-07-21 18:43:40 UTC
I tried to bibisect this one. The latest version (git checkout latest) shows the table correctly:

Version: 4.3.0.0.alpha0+
Build ID: 1581b1fc3ac82a7bd62df968226e98604a4ca52d
Comment 2 Jorendc 2014-07-21 18:51:55 UTC
Also broken on Version: 4.4.0.0.alpha0+
Build ID: 163b5fd59fe1e9b8c8a1bcac9dab069c0bcd27e9
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-07-07_07:24:52
Comment 3 Owen Genat (retired) 2014-07-22 03:06:21 UTC
Confirmed under GNU/Linux x86_64 using:

- v4.1.6.2 Build ID: 40ff705089295be5be0aae9b15123f687c05b0a
- v4.2.5.2 Build ID: 61cb170a04bb1f12e77c884eab9192be736ec5f5
- v4.3.0.3 Build ID: 08ebe52789a201dd7d38ef653ef7a48925e7f9f7
- v4.4.0.0.alpha0+ Build ID: 4aa9b041de3129f19b48e66d349f48657b73f33e (2014-07-19)

All versions display a single thin line rather than the expected table. v3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b displays the table contents but with alignment issues as indicated in bug 38066. Status set to NEW.
Comment 5 Jorendc 2014-07-22 22:18:18 UTC
Hi Miklos,

When I place the insertion of PROP_HEIGHT outside your introduced if-statement of commit 970160f78ef6cc7abacfa252daa8451e1f0117bb , this zero-col-height looks fixed. But counterside is that your unittest of that commit fails (actual height = 41 instead of 0).
Opening this test document (bnc865381.docx) with following patch included or excluded looks exactly the same (will attach a screenshot in a second). Left is as it now is, right is with patch bellow applied.

diff --git a/writerfilter/source/dmapper/TablePropertiesHandler.cxx b/writerfilter/source/dmapper/TablePropertiesHandler.cxx
index 0edbd71..0c97602 100644
--- a/writerfilter/source/dmapper/TablePropertiesHandler.cxx
+++ b/writerfilter/source/dmapper/TablePropertiesHandler.cxx
@@ -103,9 +103,9 @@ namespace dmapper {
                         // In case a cell already wanted fixed size, we should not overwrite it here.
                         if (!pManager || !pManager->IsRowSizeTypeInserted())
                             pPropMap->Insert( PROP_SIZE_TYPE, uno::makeAny( pMeasureHandler->GetRowHeightSizeType() ), false)
-
+                                       }
                         pPropMap->Insert( PROP_HEIGHT, uno::makeAny(pMeasureHandler->getMeasureValue() ));
-                    }
+                    //}
                     insertRowProps(pPropMap);
                 }
             }

Any idea?

Thanks in advance,
Joren
Comment 6 Jorendc 2014-07-22 22:19:04 UTC
Created attachment 103306 [details]
left, original as it now is. Right with patch I mention in comment 5
Comment 7 Jorendc 2014-09-14 18:48:23 UTC
It looks like it does show the content as before.
Tested using Mac OSX 10.9 with LibreOffice Version: 4.4.0.0.alpha0+
Build ID: 1ebbb8bceb9f8e5876894f04b2e52cf772eb06a0
TinderBox: MacOSX-10.9-x86_64@53, Branch:master, Time: 2014-09-14_06:47:36
Comment 8 Jorendc 2014-09-14 18:48:41 UTC
Created attachment 106285 [details]
How it looks now
Comment 9 Robinson Tryon (qubit) 2015-12-17 04:35:40 UTC
Migrating Whiteboard tags to Keywords: (filter:docx, bibisected)
[NinjaEdit]