Bug 101217 - Setting the column width and height should not round the values causing compounding errors
Summary: Setting the column width and height should not round the values causing compo...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Winston T
URL:
Whiteboard: target:7.2.0 target:7.3.0 target:7.3....
Keywords: difficultyBeginner, easyHack, skillCpp, topicUI
Depends on:
Blocks: Writer-Tables
  Show dependency treegraph
 
Reported: 2016-07-30 04:38 UTC by Nathan Shearer
Modified: 2021-11-26 17:26 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
11.99 instead of 12.00 mm (13.00 KB, image/jpeg)
2017-09-16 13:29 UTC, Hermann Rochholz
Details
Column width rounding error when entering values (25.37 KB, image/png)
2021-02-09 19:35 UTC, Nathan Shearer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nathan Shearer 2016-07-30 04:38:31 UTC
Create a spreadsheet that is 8.5x11 standard letter with no headers or footers. Set your cell width to exactly 1.0625" (that is exactly 8 columns or 1/8 of 8.5").

Set your cell width again, notice the value is rounded. Add borders and create a print preview. The compounding errors results in bad alignment of the cells.

Since high resolution printers (600dpi) are common, I should be able to set arbitrarily precise measurements for my cell width and height. rounding to 1/100 of an inch is arbitrarily limited and the compounding errors are causing alignment problems.
Comment 1 Xisco Faulí 2017-03-08 11:50:38 UTC
Dear Reporter,
Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ?
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Comment 2 Nathan Shearer 2017-03-08 17:54:48 UTC
Set the column width to 0.125", and it is forcibly rounded to 0.13"

Confirmed, still exists in 5.3.0.3
Comment 3 Nathan Shearer 2017-07-24 20:44:53 UTC
Retested and I can confirm this bug still exists in:
4.4.4.3
5.1.2.2
5.2.7.2
5.3.4.2
Comment 4 Hermann Rochholz 2017-09-16 13:29:27 UTC
Created attachment 136285 [details]
11.99 instead of 12.00 mm

I have a similar detection: 
LO Writer 5.4.0.3 (actual mid sept 2017)

When swithing units to mm it always get's a rounding error e.g. in tables.

E.g. I switch TABLE HEIGHT to 12.00 mm
and when opening it's always 11.99 mm

It's not severe, but it confuses. 
I make an attachment.

Hermann
Comment 5 Buovjaga 2017-10-28 15:10:44 UTC
(In reply to Hermann Rochholz from comment #4)
> Created attachment 136285 [details]
> 11.99 instead of 12.00 mm

How do I get this dialog?
Comment 6 Hermann Rochholz 2017-10-28 18:19:20 UTC
(In reply to Buovjaga from comment #5)
> (In reply to Hermann Rochholz from comment #4)
> > Created attachment 136285 [details]
> > 11.99 instead of 12.00 mm
> 
> How do I get this dialog?

You have to switch the dimensions into mm under 

Extras -> Options -> LO Writer -> Allgemein (?general?) -> Units
Comment 7 Buovjaga 2017-10-29 09:04:34 UTC
(In reply to Hermann Rochholz from comment #6)
> (In reply to Buovjaga from comment #5)
> > (In reply to Hermann Rochholz from comment #4)
> > > Created attachment 136285 [details]
> > > 11.99 instead of 12.00 mm
> > 
> > How do I get this dialog?
> 
> You have to switch the dimensions into mm under 
> 
> Extras -> Options -> LO Writer -> Allgemein (?general?) -> Units

Yes, I use mm by default, but how do I get the dialog shown in your screenshot?
Comment 8 Hermann Rochholz 2017-10-29 12:03:05 UTC
(In reply to Buovjaga from comment #7)
> (In reply to Hermann Rochholz from comment #6)
> > (In reply to Buovjaga from comment #5)
> > > (In reply to Hermann Rochholz from comment #4)
> > > > Created attachment 136285 [details]
> > > > 11.99 instead of 12.00 mm
> > > 
> > > How do I get this dialog?
> > 
> > You have to switch the dimensions into mm under 
> > 
> > Extras -> Options -> LO Writer -> Allgemein (?general?) -> Units
> 
> Yes, I use mm by default, but how do I get the dialog shown in your
> screenshot?

Table line height
Comment 9 Buovjaga 2017-10-29 12:15:44 UTC
Ok, I confirm:
Menu Table - Size - Row height

In older versions: right-click table - Row - Height.

Arch Linux 64-bit, KDE Plasma 5
Version: 6.0.0.0.alpha1+
Build ID: 7a2e7c32d38db02aaa5d78d5e8aaf86cabfde586
CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on October 28th 2017

Arch Linux 64-bit
LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4
Comment 10 QA Administrators 2019-02-09 03:44:53 UTC Comment hidden (obsolete)
Comment 11 QA Administrators 2021-02-09 05:08:50 UTC Comment hidden (obsolete)
Comment 12 Nathan Shearer 2021-02-09 19:35:03 UTC
Created attachment 169632 [details]
Column width rounding error when entering values
Comment 13 Nathan Shearer 2021-02-09 19:39:34 UTC
The bugzilla daemon requested that I verify this bug still exists.

4 YEARS later and this trivial bug still exists.

The cell dimensions are being forcibly rounded to values and distorting spreadsheet dimensions. I have actual documents that I cannot open/edit/save because this software is mangling the cell dimensions.
Comment 14 Regina Henschel 2021-02-09 21:00:13 UTC
The 12mm to 11.99mm problem is not trivial. The internal unit is Twips as integer value. 1 Twips = 127/7200 mm and 1 mm = 7200/127 Twips.

12.00mm = 680.3149... Twips ≈ 680 Twips
680 Twips = 11.9944... mm ≈ 11.99 mm
And on the other hand, for the next Twips value you get
681 Twips = 12.01208... mm ≈ 12.01 mm

Twips is used, to get a better conversion with point: 1pt = 20 Twips.

I agree, that the input fields in the column size dialog should have more decimal places, so that it is possible to enter n/8 values.
Comment 15 Heiko Tietze 2021-02-11 11:21:31 UTC
(In reply to Regina Henschel from comment #14)
> I agree, that the input fields in the column size dialog should have more
> decimal places, so that it is possible to enter n/8 values.

Would another decimal point in the UI solve the Twips problem?
Comment 16 Regina Henschel 2021-02-11 12:16:14 UTC
(In reply to Heiko Tietze from comment #15)
> (In reply to Regina Henschel from comment #14)
> > I agree, that the input fields in the column size dialog should have more
> > decimal places, so that it is possible to enter n/8 values.
> 
> Would another decimal point in the UI solve the Twips problem?

Not the Twips problem, but the original reported problem. Especially in an environment with US measurement system, you need at least 4 decimals. I personally  see no need to restrict the column width input field at all. Currently I workaround the problem in using Millimeter as unit.
Comment 17 Nathan Shearer 2021-02-11 18:13:00 UTC
1 Twip is defined as exactly 1/1440 of an inch. I would recommend removing the restriction on the UI altogether and allow unlimited decimals. Internally the software may round to the nearest twip since that seems to be a design limitation.

Any other bugs caused by removing this restriction can also be discovered and tracked, resulting in an overall better software solution.
Comment 18 Heiko Tietze 2021-02-12 08:11:10 UTC
(In reply to Nathan Shearer from comment #12)
> Created attachment 169632 [details]
> Column width rounding error when entering values

This dialog is from Calc but the ticket is filed against Writer. This module shows five input fields for col widths and if we add decimal points it clutters heavily. I'd prefer a more precise rounding.
Comment 19 Nathan Shearer 2021-02-12 09:53:57 UTC
I must have chosen Writer by mistake when I opened the bug. I encountered it in Calc when I tried to make a spreadsheet that divided a page into exactly 8 columns.

I have to disagree on the argument that rounding values and therefore changing the users explicit input is preferable because it can help reduce UI clutter. The UI does not need to change at all since the text fields will scroll as they do right now.

Imagine if a Bank suggested that they should round your balance because it reduces clutter. I'm sure they would always round down too ;)
Comment 20 Heiko Tietze 2021-02-12 12:13:44 UTC
Fair enough. Code pointer for easy hack: In sc/source/ui/view/cellsh3.cxx, method

ScopedVclPtr<AbstractScMetricInputDlg>pDlg(pFact->CreateScMetricInputDlg(pTabViewShell->GetFrameWeld(), "ColWidthDialog", nCurHeight, STD_COL_WIDTH, eMetric, 2, MAX_COL_WIDTH));

change the value 2 after eMetric to 4.

For consistency it would be good to do the same at 

ScopedVclPtr<AbstractScMetricInputDlg>pDlg(pFact->CreateScMetricInputDlg(pTabViewShell->GetFrameWeld(), "RowHeightDialog", nCurHeight, ScGlobal::nStdRowHeight, eMetric, 2, MAX_ROW_HEIGHT));
Comment 21 Winston T 2021-02-16 03:46:17 UTC
Do these two need to be changed as well?

ScopedVclPtr<AbstractScMetricInputDlg> pDlg(pFact->CreateScMetricInputDlg( pTabViewShell->GetFrameWeld(), "OptimalColWidthDialog", ScGlobal::nLastColWidthExtra, STD_EXTRA_WIDTH, eMetric, 1, MAX_EXTRA_WIDTH));

ScopedVclPtr<AbstractScMetricInputDlg> pDlg(pFact->CreateScMetricInputDlg(                        pTabViewShell->GetFrameWeld(), "OptimalRowHeightDialog",                      ScGlobal::nLastRowHeightExtra, 0, eMetric, 1, MAX_EXTRA_HEIGHT));
Comment 22 Heiko Tietze 2021-02-16 09:01:10 UTC
(In reply to Winston T from comment #21)
> Do these two need to be changed as well?

Yes, it wont hurt to have more digits for the optimal col width / row height.
Comment 23 Mike Kaganski 2021-03-02 08:13:37 UTC
(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. The problem is that we have our own internal size unit (different in different places by the way!), and we convert between them internally left and right using whole numbers. So the more precisely you make your input, the more likely it is that you stumble down the effect of this internal rounding, when your thousandths of inch would get converted to twips, then mm/100s, then back to twips, then to pixels in a virtual device ... this is internal ugliness caused by us not using e.g. EMUs to avoid this problem, but it is what it is. And you will get a different value in the end after round-tripping it. And will naturally file a bug report ;-P
Comment 24 Commit Notification 2021-03-16 14:50:32 UTC
Winston Min Tjong committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/872ab577ccc4626f4720ae71cc298dca8e2968f4

tdf#101217 Change row height and col width decimal places to 4

It will be available in 7.2.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.
Comment 25 Commit Notification 2021-03-17 11:31:33 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/32a0b409282554df7d66b7212ddd0fe187f86690

Revert "tdf#101217 Change row height and col width decimal places to 4"

It will be available in 7.2.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.
Comment 26 Commit Notification 2021-04-22 16:24:07 UTC
Winston Min Tjong committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/ad8edac43e73555bc2055514300c5b81a1bb04ea

tdf#101217 Change row height and col width decimal places to 4

It will be available in 7.2.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.
Comment 27 stragu 2021-08-13 12:10:40 UTC
Verified in:

Version: 7.2.0.2 / LibreOffice Community
Build ID: 614be4f5c67816389257027dc5e56c801a547089
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

I can now see a precision of 4 decimals.

My concern with this is that it now "exposes" the rounding. For example, setting the column width to 2.5 cm results in a width of 2.4994 cm. Wondering if people will see this as a bug, when it actually is just more transparency on what already used to happen.
I don't know if I understand this well, but if further decimals are exposed, shouldn't also the precision be pushed further at the same time, so the exposed decimals don't jump around so much?
Comment 28 Mike Kaganski 2021-08-13 12:34:00 UTC
(In reply to stragu from comment #27)
> My concern with this is ...

what comment 23 already warned you in the first place. And no, you can't push precision (at least without a major rework).
Comment 29 Commit Notification 2021-11-26 13:51:13 UTC
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.
Comment 30 Heiko Tietze 2021-11-26 13:55:07 UTC
Reverted the patch after discussion on bug 144247. Please use a different unit for more precise input.
Comment 31 Commit Notification 2021-11-26 17:26:28 UTC
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.