Bug 75916 - Unresetted hidden decimals in positions and sizes
Summary: Unresetted hidden decimals in positions and sizes
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: framework (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: low minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Options-Dialog
  Show dependency treegraph
 
Reported: 2014-03-08 18:31 UTC by Callegar
Modified: 2023-02-23 03:25 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Callegar 2014-03-08 18:31:07 UTC
This is probably inherited from the openoffice code base

To reproduce:
-------------
1) Open Libreoffice impress (or draw)
2) Open the Tools->Options dialog
3) Go to the Libreoffice Impress -> General tab
4) Set the unit of measurement to millimeters
5) Draw something
6) Open the position and size dialog for the just drawn object
7) Set the object x position to 61.04 mm
8) Open the Tools->Options dialog
9) Go to the Libreoffice Impress -> General tab
10) Set the unit of measurement to centimeters
11) Open the position and size dialog for the just drawn object
12) Note how the x position reads 6.10 cm (we know that this is in fact 6.104 cm)
13) Type 6.10cm as the x position, press OK. Now the position should be 6.10 cm
14) Open the Tools->Options dialog
15) Go to the Libreoffice Impress -> General tab
16) Set the unit of measurement to millimeters
17) Open the position and size dialog for the just drawn object
18) Note how the x position reads 61.04 mm. Our editing action at point 13 has not reset the hidden decimals (!)

In my humble opinion, even if the position and size boxes only display a fixed number of decimal digits, when the user explicitly enters a quantity with more digits, these should not be ignored. Otherwise:
1) there is no way for the user to position objects with high precision
2) there is no way to see that the user input is different from the current stored value when the difference is on decimal digits that are customarily not shown. As a consequence the value is not updated. Hence, if the currently stored value is 6.104 and the user enters 6.10, the software truncates 6.104 to 6.10, sees it as identical to the user input and does not update the value to the user input. Nasty decimal digits that cause ugly misalignements in display and print may get retained.

Furthermore, it would be nice if
1) At least one additional digit was shown when working in cm (3 instead of 2); or
2) then number of shown digits was made configurable together with the measurement unit.
Comment 1 Jean-Baptiste Faure 2014-05-01 15:57:27 UTC
Reproducible with LibreOffice 4.2.5.0.0+ under Linux / Ubuntu 14.04 x86-64.
That said O.01 mm does mean nothing on a screen, if you had one pixel in 0.01 mm that would mean your screen has a resolution of at least 2540 pixels/inch ...

Workaround: change the first decimal after the decimal separator and restore it using the up and down arrow of the value field.

Best regards. JBF
Comment 2 QA Administrators 2015-06-08 14:42:11 UTC Comment hidden (obsolete)
Comment 3 Callegar 2015-06-08 15:52:09 UTC
Bug is still present as of 4.4.4.1.0.

Don't think it is a regression. LibO has inherited from the past history and OO a lot of small glitches with respect to metric units.
Comment 4 QA Administrators 2016-09-20 10:01:11 UTC Comment hidden (obsolete)
Comment 5 Callegar 2016-09-21 08:53:46 UTC
Still present in 5.2.2.1.

Related to bug 75915

Related to OO bug https://bz.apache.org/ooo/show_bug.cgi?id=45593
Comment 6 Xisco Faulí 2017-09-29 08:49:24 UTC Comment hidden (obsolete)
Comment 7 QA Administrators 2021-02-22 04:00:21 UTC Comment hidden (obsolete)
Comment 8 QA Administrators 2023-02-23 03:25:19 UTC
Dear sergio.callegari,

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://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug