Description: Table width grows saving DOC file reload, save again and so on Steps to Reproduce: 1. Open the attached file 2. Open the Table Properties -> Notice the width being 17 cm 2. Save as DOC 3. File reload 4. Press Save 5. File reload 6. Press Save 7. File reload 8. Press Save Actual Results: 17,13 I think Expected Results: Still 17 Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha0+ (x64) Build ID: <buildversion> CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win Locale: ru-RU (nl_NL); UI: en-US Calc: CL
Created attachment 164213 [details] Example file
Created attachment 164214 [details] Example file
@Justin This one might be a bit more important compared to they lovely anchoring/wrap. As DOC maybe still commonly used BTW.. RTF does also weird things.. drifting of the left (might be unrelated) but same steps
Created attachment 164315 [details] 135672_docTableGrows.odt: exaggerated reproducer created from scratch There must be something wrong with the width calculation related to the border width. Reproduced with bibisect 3.5 and 5.3. There doesn't seem to be anything special about OP's example - so it must be true pretty much all the time.
If I disable the calculation of nRightMaxThickness, then the problem goes away, and no unit tests really complain (except minor import variations). nRightMaxThickness was introduced by commit 53d67a4e9f26689dbcce07f045ef6222bfadc27e Author: Caolán McNamara on Tue Oct 16 11:42:32 2001 +0000 #93253# Fix borders and positioning Unfortunately, there is a LOT of formatting changes in that commit, so it is hard to tell what is being attempted. Also, there was no unit test. I'm not sure what bug system this refers to. It does NOT match Apache OOo's 93253.
(In reply to Justin L from comment #5) > If I disable the calculation of nRightMaxThickness, then the problem goes > away, and no unit tests really complain (except minor import variations). > > nRightMaxThickness was introduced by > commit 53d67a4e9f26689dbcce07f045ef6222bfadc27e > Author: Caolán McNamara on Tue Oct 16 11:42:32 2001 +0000 > #93253# Fix borders and positioning > > Unfortunately, there is a LOT of formatting changes in that commit, so it is > hard to tell what is being attempted. Also, there was no unit test. I'm not > sure what bug system this refers to. It does NOT match Apache OOo's 93253. Let's test the photographic memory of Caolán :-)
The bug id is the internal StarDivision bug tracker which was internal only and so lost to history. There was no in-source document import/export infrastructure at the time, only whatever testing the internal qa dept might have had. At this distance in time I couldn't tell, except on changing it try with a msword table with super-fat borders and import/export that to see that a round trip doesn't degrade
(In reply to Caolán McNamara from comment #7) > try with a msword table with super-fat borders I like the way Caolán thinks. That's found in comment 4. ww8export contains bordercolours.odt which has a semi-large border. The negative-starting-from-left creeps more left every time, and the table grows to accommodate that fairly closely so perhaps those two are related?
proposed fixes: https://gerrit.libreoffice.org/c/core/+/101187 : fix left table position https://gerrit.libreoffice.org/c/core/+/101188 : fix table width
Running a bit ahead.. however seeing some flavours here They real conservative route pushing this only to 7.1. Backporting into 7.0.2 after some testing. Or being slightly bold and attempt to get into 7.0.1 as last minute I opt slightly for the last option. As LibreOffice 7.0.1 is (a) still advertised for enthusiasts. (b) Intention is to grow more stable over time. So how sooner this pushed how more this in line with growing stable. (c) We need a tester group; fast. (d) It fixes a rather substantial (hideous) flaw, IMHO. So waiting for 7.1 doesn't make much sense to me.. And I don't see a point in time where we can be certain of it being safe. They bar getting higher at every release in they 7.0 branch (e) And there is some room to pull this before 7.0.5 if there are substantial side-effects. However, only giving my vision. It doesn't fit well with the motto no regression on my watch in release builds. As there are risks involved..
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/76ec8b52da8ffe8a21c223937c7dbe960f12ebda tdf#135672 doc import: fix left table position It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0b495a630b7c449b3e8911d3970449776e502ce9 tdf#135672 doc import: fix table width It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Telesto from comment #10) I'm not intending to backport because -it is unclear why this code which was specifically added is now wrong. -this problem is very old with no bug reports written about it. -I'm not personally concern about it, even though in my org we default to save as .doc