Description: Row height in Calc was 0,45 cm now it's 0,4516. Set rowheight to 10 it will be 9,9995 cm Steps to Reproduce: 1. Open Calc 2. Right click Column 1 and select row height Actual Results: 0,4516 Expected Results: 0,45 Reproducible: Always User Profile Reset: No Additional Info: Found in 7.3 and in Version: 7.2.0.1.0+ (x64) / LibreOffice Community Build ID: 2a265bdda19d86437c6eb4d8deb0057d5b45e97f CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL not in 7.1
Created attachment 174707 [details] Bibisect log Bisected to: author Winston Min Tjong <winstontjong@gmail.com> 2021-04-08 14:55:00 -0700 committer Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> 2021-04-22 18:23:32 +0200 commit ad8edac43e73555bc2055514300c5b81a1bb04ea (patch) tree 542afabdedc85bdaba2836b3d3488293a0679b7f parent 35e4a45260f128f353d25e2a2f2b800e6bd11d61 (diff) tdf#101217 Change row height and col width decimal places to 4 Bug 101217 - Setting the column width and height should not round the values causing compounding errors This patch fixes the problem caused by rounding errors by increasing the number of decimal places for row height, optimal row height, column width, and optimal column width to 4. https://cgit.freedesktop.org/libreoffice/core/commit/?id=ad8edac43e73555bc2055514300c5b81a1bb04ea
And what to do, round to 4 or not.
(In reply to m.a.riosv from comment #2) > And what to do, round to 4 or not. Well 4 digits seems excessive. 2 digits would be enough.. I think
(In reply to Mike Kaganski from bug 101217 comment #23) > (In reply to Heiko Tietze from comment #22) > > it wont hurt to have more digits for the optimal col width / row height. > > Heh. I would not be so sure. Of course, having more digits seems innocent, > until you think about imminent new bug reports after fixing this. :-)
IMHO having the needed digits to get the right set up, would the best in the long term.
Noticed this as well and was very confused but did not have the capacity to report. Entering a number and receiving something different by the software is a recipe for user frustration. Setting to NEW, I don't believe showing 4 digits is what users want or need. I acknowledge lacking the technical background of understanding the rounding issues resulting in different values than what the user entered, but there must be a better way to handle this. > "having the needed digits to get the right set up, would the best" What do you mean by that?
If LO manage 4 to set up, then 4 digits it's the right to show. Otherwise, users don't see the true value. Maybe the difference it's not important on screen, but it could be on printing.
Eike, you are assigned on bug 138920. Will this also improve the situation here? If not, we should better revert the patch that turned the two digits into four.
No, that display string thing is unrelated because here we have the conversions between cm/whatever/twips involved, the 0,45cm was a rounded value and people complained they couldn't see exact values and now people complain they don't see the rounded values anymore.
(In reply to Eike Rathke from comment #9) > No, that display string thing is unrelated because here we have the > conversions between cm/whatever/twips involved, the 0,45cm was a rounded > value and people complained they couldn't see exact values and now people > complain they don't see the rounded values anymore. I do get the "need" for exact values. Not much of issue that this being possible either [showing rounding and internally being unrounded being worse, IMHO: similar topic at bug 144279] The "main issue" being that the default cell width being a 4 digit number. I mostly don't think in 4 digits when wanting to change the cell size. Excel sets the cell size in points; which produces nice round numbers :-) and not depending on 'locale' (inch/cm) A radio button in the row height dialog.. Default for PT and another one for inch/CM would give most flexibility: if there is also a general setting for setting it to pick PT/CM/INCH whatever'. The inch/cm factor has it's advantages; see bug 101217 However there objections to to this 'solution' too.. Like the interface bloat topic :-) And I would certainly hold off any change, to check if more bug reports - complains - appear...
(In reply to Telesto from comment #10) > Excel sets the cell size in points LOL. Excel sets the widths of cells in *number of average widths of characters of the font set to default for the document* - if you believe that's a descent measurement unit, I'd disagree with you.
(In reply to Mike Kaganski from comment #11) > LOL. Excel sets the widths of cells in *number of average widths of > characters of the font set to default for the document* - if you believe > that's a descent measurement unit, I'd disagree with you. When proposing PT I only looked at perspective/facet of rounding (not in depth review of all pro's and cons). Every measure has own advantage/disadvantage. I'm able to work with points too, but that probably says something about the depth of my Calc usage. I would really annoyed when wanting a cell to be say exactly 2 cm, and having the input only allowing points. FWIW: Don't take my proposals as well analyzed.. Only proposing something - brainstorming - to figure out some alternative. Having PT cell size visible somewhere would improve compatibility with MSO/Excel, I guess? I speculate Calc is currently converting the cell size to PT on xls xlxs export? Note: I would go for the wait and see approach. Will people start report they 4 digit stuff or not. It might end up being a trivial non-issue :-). The reason I reported this was because the change from 2 digits to 4; which was kind of surprising to see.
*** Bug 145140 has been marked as a duplicate of this bug. ***
Patch https://gerrit.libreoffice.org/c/core/+/123802 shows two digits by default but 4 in case of user-defined values. The rounding problem remains and it is not possible to get back to 2 digits by using 0.45cm as this value is internally 0.44992 (or the like). Was thinking of a comparison like <user input> minus <default> greater 0.01 but this won't help in all cases. It does for 0.45cm (ScGlobal::nStdRowHeight) but fails for 10cm (9,9995) resp. 10.5cm (10,5004) or 10.05cm (10,0506). The only solution is to store the actual input along with the internal value.
*** Bug 145619 has been marked as a duplicate of this bug. ***
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e396017b598e6ef161e71f18638b4d94cd92e6ee Resolves tdf#144247 - Change display precision of row height / column width It will be available in 7.3.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.
Issue verified in Version: 7.3.0.0.alpha1+ / LibreOffice Community Build ID: fcad2503ede92b515076f9bb3162855dcc2c575d CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded @Heiko, thanks for fixing this issue!!
Heiko Tietze committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/c6fb8ffc6a35d94002a2c5b5b36c228c161cde85 Resolves tdf#144247 - Change display precision of row height / column width It will be available in 7.2.4. 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.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1d98c34e647edb44457bcc4ac2d6ff7ec237f556 tdf#144247: sc: Add UItest It will be available in 7.3.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.
I tested in 7.3 on Linux and 0,45 became 0,4498. Shouldn't be rounded? Version: 7.3.0.0.alpha1+ / LibreOffice Community Build ID: fcad2503ede92b515076f9bb3162855dcc2c575d CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
Heiko Tietze committed a patch related to this issue. It has been pushed to "libreoffice-7-2-3": https://git.libreoffice.org/core/commit/b9a3b141d09450a94d601d60f139d17b2ae07040 Resolves tdf#144247 - Change display precision of row height / column width It will be available in 7.2.3. 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 BogdanB from comment #20) > I tested in 7.3 on Linux and 0,45 became 0,4498. Shouldn't be rounded? The default value is 0,45 and will be shown with two digits. If you change it something else you get four digits. Setting back does not return to two digits since you cannot enter the precise value.
(In reply to Heiko Tietze from comment #22) > (In reply to BogdanB from comment #20) > > I tested in 7.3 on Linux and 0,45 became 0,4498. Shouldn't be rounded? > > The default value is 0,45 and will be shown with two digits. If you change > it something else you get four digits. Setting back does not return to two > digits since you cannot enter the precise value. But if I change 0,45 to 0,45 it shoulnd't became 0,4500? Instead of 0,4498?
What you see is not what you get and to enter 0,45 is not equal to implement a constant 0,45. But I get the point and agree from the UX POV. It's just that anything else is beyond my skills. Feel free to reopen.
Once more: there is no measurement in rounded centimetres, the internal measurement is in TWIPs (twentieth of an inch point) (where a point(pt) is the smallest unit of measure in typography). The standard row height is 256 twips that is 0.4515584cm, this bug complains users see the rounded to 4 decimals value 0.4516cm instead of the even more rounded 0.45cm, and now only if the current row height is the standard row height it is displayed as rounded 0.45cm. If 0.45cm is entered that results in 255.11650320313 twips that get rounded to 255 twips, which is not equal to the standard 256 twips hence is not displayed rounded to 2 decimals but to 4, where 255 twips converted to cm is 0.4497945cm that is displayed as 0.4498cm
Ok. Thanks for explaination. Everything fine then.
(In reply to BogdanB from comment #23) > But if I change 0,45 to 0,45 it shoulnd't became 0,4500? Instead of 0,4498? (In reply to BogdanB from comment #26) > Everything fine then. Not in my opinion. If the commit at comment 16 can be broken that easily please revert it. It has no real benefit, IMHO. Still appreciate the try though! Is there no sane way to make it show 0,45? Like rounding the input field value up/down to 2 digits before pushing that number to the edit box, while internally using 4 digits. Yes the GUI won't show exactly what the backend is doing; not ideal (optical illusion). However entering 0,45 and ending up with 0,4498 is as confusing, IMHO From end-user perspective this is really obscure. Alternative route is adding the explanation to the documentation.
*** Bug 145813 has been marked as a duplicate of this bug. ***
(In reply to Telesto from comment #27) > Is there no sane way to make it show 0,45? Like rounding the input field > value up/down to 2 digits before pushing that number to the edit box, while > internally using 4 digits. You did not understand. Nothing is internally using 4 decimals (digits). Internally integer TWIPs are used. Go back to my comment 25 and read it again.
(In reply to Eike Rathke from comment #29) > (In reply to Telesto from comment #27) > You did not understand. Nothing is internally using 4 decimals (digits). > Internally integer TWIPs are used. Go back to my comment 25 and read it > again. Mea culpa. However the 'idea' still stands, in my perception. 0,45 cm = 255.11650320313 twips -> ending up being 255 twips = 0.4497945cm 1 twip 0.0017638889 cm So if some enters 0,45 cm it should be 255.11650320313 twips. However because of being integer value it will be 255 twips. The integer value 255 twips is yet again used to show the defined row height in the UI: showing 0.4497945cm My 'proposal' is to apply rounding for the 'twips -> cm' conversion. So 255 twips shows in the dialog as 0,45 cm. While internally 255 twips = 0.4497945cm = being used.
(In reply to Telesto from comment #30) > My 'proposal' is to apply rounding for the 'twips -> cm' conversion. So 255 > twips shows in the dialog as 0,45 cm. While internally 255 twips = > 0.4497945cm = being used. This is exactly what had changed in commit ad8edac43e73555bc2055514300c5b81a1bb04ea (see comment 1). So your proposal is: "please revert that".
Maybe use 2 digits in case of 255 twips +- 0.5. But this would work only for cm.
Hi, not a LO developer, but found this bug by chance and wanted to give my 0.02$: When Libreoffice is using integer twips internally and 1 twip is between 0.001 and 0.002 cm, is there any need to show 4 decimals at all? The smallest possible increment/decrement will be in the third decimal and the users will be confused why it LO doesn't respect smaller changes, even though 4 decimal places are shown - it implies that those are somehow meaningful. My proposal: Reduce shown precision to 3 decimal places. Tbh that could still be confusing (sometimes changing the value by 0.001 would internally round to the same twip), but every change by at least 0.002 would mean a change by 1 twip. Also: If you round 255 twips = 0.4497945cm to the third decimal, you'll receive 0.450 and the UI confusion discussed here would be gone. (It would also mean that the user couldn't distinguish between 255 and 256 twips. But - if a user needs that kind of control - maybe there should be an expert option to show and edit the internal twip setting by the user.)
Input in twips is already possible, just enter "256 twip" (with or without space, plural "twips" is also accepted) to set back to the default row height (same as checking the Default box). The display probably would also be possible when adding Twips to the measurement units under Tools -> Options -> Calc -> General, Metrics. Btw, selecting Point there displays a more exact value as 20 twips are 1 point, the default 256 twips are 12.80pt, 255 twips are 12.75pt (now needlessly displayed as "12.7500 pt" ...). And as font heights are also given in pt the relation between font height and row height becomes clearer. Most spreadsheet users just tend to not care at all about such typographical details and rather illogically expect a "correctly" rounded cm value where there is none.
(In reply to NovarthaWoW from comment #33) > My proposal: Reduce shown precision to 3 decimal places. The reason for 4 digits is discussed in bug 101217. Please always keep different units in mind.
(In reply to Heiko Tietze from comment #35) > The reason for 4 digits is discussed in bug 101217. Please always keep > different units in mind. There never was a real need for that change. It was only done because: (1) users do not know that they can use any unit when entering values (see comment 34; it could be improved by a good in-place help like tooltips, or even by improving metric controls to add a unit selector); and (2) because the change looked trivial and non-controversial (and the implementer chose to ignore my warning). A user who needs finer units is always able to change display units in settings to more fine-grained. Both mm and pt provide the maximum fidelity possible for the application (that uses mm/100 in some places internally, and twips in other places).
I do see merits for people tried to solve at bug 101217. Both bug 101217 and the bug here primarily rounding in the conversion from metric to twips, I think The assumption was that using 4 digits would make it (more) exact calculation (across the board for all units). However converted into twips (and rounded) to integer it will be off by definition. So it's more an coincidence that worked well at bug 101217 --- The 4 digits approach seems wrong anyhow. Looking at comment.xml of a row manually height set to 0,45cm. It's stored as 0,45cm in file, and shows 0,4498 cm in dialog. Which surely isn't that same. Not even sure how many digits are allowed based on ODS specifications (XLXS). So measurement problem for bug 101217 appears to be internal conversion issue (or cell height being defined in twips). ---- Mike is also right about the wrong metric being used. So instead of showing more digits, a different unit should have been used. You normally don't use M (meter) to define 1 millimeter. And if you need a m, you can instead of 1,015m use 1015mm. Round issues at the mm to twips conversion still possible, though. -- I guess, the problem at bug 101217 exacerbate that the cell height for each individual cell being converted to twips (and rounded up)? Which creates even bigger mismatch. Not sure if you can take the sum of height of all cells within a printing range, convert this to twips and if (still) necessary scale a bit it to fit on the targeted paper size?
(In reply to Mike Kaganski from comment #36) > (In reply to Heiko Tietze from comment #35) > > The reason for 4 digits is discussed in bug 101217. Please always keep > > different units in mind. > > There never was a real need for that change. It was only done because: (1) > users do not know that they can use any unit when entering values (see > comment 34; it could be improved by a good in-place help like tooltips, or > even by improving metric controls to add a unit selector); and (2) because +1 Users need to know how, without down to the hell to find out.
Offtopic. (In reply to Telesto from comment #37) > I do see merits for people tried to solve at bug 101217 ... I also *see* what people tried to do there. And I only can tell you that we have a big problem in out UX attitude, caused by fashionable "Developers do no understand users" and "Users should define the direction" stanzas. UX should not rely on people making decisions being "just" users. They must be a very rare breed of (a) highly experienced users; (2) having good understanding of the architectural principles the program is created around; (3) despite of all that, having no hostility to workflows not fitting well into the said principles, and being very friendly to all categories of users; (4) have good experience of resolving problems of both basic users, and advanced users (esp. caused by basic users abusing features); (5) willing to build the big picture of existing problems, instead of rushing to "fix" small tasks without looking how that fits the big picture. Without that, taking an easy decision to "fix bug 101217" because "we see the problem people *perceive*, but we do not care to understand the real problem standing behind that perceived problem, and build some solid solution fitting this and other related issues" is "obvious". I recall Wikipedia article https://en.wikipedia.org/wiki/XY_problem : > In 1980's "Applied Management Science: A Quick and Dirty Approach",[2] Gene > Woolsey described a famous example of solving the wrong problem. Management > was concerned about complaints that people had to wait too long for elevators, > and so spent a lot of time and money researching how to schedule elevators to > reduce the wait times. Woolsey pointed out that they were trying to solve the > wrong problem. The real problem was that "people were complaining". The > installation of large mirrors in the lobby gave people something to do, and > the complaints were drastically reduced. Heiko does his best here, but one person's effort is not enough here; and I see many others participating in UX being almost aggressive in their "I look at it from a basic user's perspective".
Patch https://gerrit.libreoffice.org/c/core/+/125871 reverts the shenanigans completely.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f82f6a2714fbf7882eb1d77351574392ae8e4c27 Reverts tdf#144247 tdf#101217 - 4 digits in row height/col width It will be available in 7.3.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.
Heiko Tietze committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/d808f4f6df7fc987a918670c21162b21a0f8bd9f Reverts tdf#144247 tdf#101217 - 4 digits in row height/col width It will be available in 7.3.0.0.beta2. 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.
Heiko Tietze committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/3529262802b77d7c5993d8184e69434b59a6bab2 Reverts tdf#144247 tdf#101217 - 4 digits in row height/col width It will be available in 7.2.4. 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.
7.2.4 was a hotfix release, updating target in status-whiteboard