Description: UI: Checking Relative width for table with 12 cm and unchecking again results in 11,90 cm Steps to Reproduce: 1. open the attached file 2. Table -> Properties -> Table 3. Check Relative 4. Uncheck relative Actual Results: 11,90 Expected Results: 12 Reproducible: Always User Profile Reset: No Additional Info: Found in 7.1 and in LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
No attached file
1. Open attachment 163229 [details] 2. Table -> Properties -> Table 3. Check Relative 4. Uncheck relative
@Caolan As are already looking into they table dialog code, you might be interested in this -> Note: still UNCONFIRMED but not to hard to test
One thing I noticed is that this only seems to happen after the first time. If I reset the settings, then checking and unchecking Relative means that the width remains the same. Version: 7.1.0.0.alpha0+ Build ID: 52820b52b3bca45e2db527d1cc5f4488b2e0b9d0 CPU threads: 8; OS: Mac OS X 10.15.6; UI render: default; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Umm, who would really care? Plus, this mostly makes sense. Percentage changes to the table size to the nearest integer percentage. It can't be 71.23988456886534% - it has to be 71 or 72%. Thus, when you change it back to cm (or whatever high-precision unit you are using), you will get a slightly different table size from the original 12cm. (Yes, I did notice that it shrunk from 71% to 70% and then stabilized, so there is probably a silly double rounding down happening here, but it is extremely irrelevant in my mind.) We can make this a simple-hack instead of closing it as NOTABUG. The code is likely in sw/source/ui/table/tabledlg.cxx. Also, bug 134881 might be helpful. So for the record, this is what I see would need fixing. 1.) notice the table size is 12cm. change to relative. Now it is 71%. OK. 2.) go to table properties again. Uncheck relative. Now it is 11.90 cm. OK 3.) go to table properties again. Check relative. Now it is 70%. OK 4.) repeat until you lose the skin on your finger tips. (it always remains on 70%). So the problem is that it should remain on 71%, and not drop to 70%.
(In reply to Justin L from comment #5) > Umm, who would really care? FWIW: Kind of stumbled upon. In the hunt for the cause for bug 107665. I still assume it's caused by some rounding error.. causing the drop out of automatic (relative) to absolute. And having a habit to use embedded tables on regular basis.. And moving internal borders quite a lot.. where absolute means embedded tables not following sizes anymore. [Kind of very subtle hint; but give a finger and the take whole hand]. However, recalling the last time, where Mike was nice to implement another unwanted scroll blockade.. where I somehow kept finding new area's. Mike fixed a couple more before finally bailing out.. but intended to do one issue, I assume..
Retested. the same Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 2f4f4cbeb8e50081d607b86b0475b93971c40ab8 CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded