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
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
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
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.
Created attachment 103296 [details] bibisectlog bibisected range: http://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=50d20866aa90150680e6d39998081fc148638c73..1eeb20f3958666ec6ba6e0fcf52e92e5eb447a14 Maybe introduced by http://cgit.freedesktop.org/libreoffice/core/commit/?id=970160f78ef6cc7abacfa252daa8451e1f0117bb or http://cgit.freedesktop.org/libreoffice/core/commit/?id=48b5b7641d0df960558082e8948da8598f801264
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
Created attachment 103306 [details] left, original as it now is. Right with patch I mention in comment 5
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
Created attachment 106285 [details] How it looks now
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.