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
I can confirm that the bug is present in Version: 24.8.4.2 (AARCH64) / LibreOffice Community Build ID: bb3cfa12c7b1bf994ecc5649a80400d06cd71002 CPU threads: 8; OS: macOS 14.5; UI render: Skia/Metal; VCL: osx
I noticed that when the relative box is first checked, the width is 71% and the right/left spacings are 15%. 71% + 15% + 15% = 101% ??
Nam: remember to change the status to assigned while changing the assignee to yourself.
Going off on my previous comment, the first time the relative box is checked, the width is 71% and the right/left spacings are 15% resulting in a combined value of 101%. Subsequent toggling results in the width being 70% and R/L spacings being 15% each. So instead of making subsequent toggles be 70%, would it be more correct to make the first toggle 70% instead of 71%?