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.
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.
Set the column width to 0.125", and it is forcibly rounded to 0.13" Confirmed, still exists in 5.3.0.3
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
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
(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?
(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
(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?
(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
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
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear Nathan Shearer, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Created attachment 169632 [details] Column width rounding error when entering values
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.
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.
(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?
(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.
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.
(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.
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 ;)
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));
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));
(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.
(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
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.
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.
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.
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?
(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).
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.
Reverted the patch after discussion on bug 144247. Please use a different unit for more precise input.
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
FIXED > REVERTED > WONTFIX