Bug 44267 - Two decimal digits are insufficient for specifying object position and size
Summary: Two decimal digits are insufficient for specifying object position and size
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
3.5.0 Beta2
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 67232 108975 (view as bug list)
Depends on: 103322
Blocks: Draw-UX
  Show dependency treegraph
 
Reported: 2011-12-29 04:43 UTC by sergio.callegari
Modified: 2019-06-09 08:22 UTC (History)
8 users (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 sergio.callegari 2011-12-29 04:43:17 UTC
Problem:

It happens quite frequently to have two graphical elements (say two infinitely thin lines) whose extremes appear to be aligned when looking at their position in the position and size window (e.g. same x or same y coordinate).

However, if you draw a connector between the two objects, at certain zoom levels the connector does not look straight (showing that there is in fact some misalignement between the two objects).

This most frequently happens when one of the two objects is copied and then moved around. Probably, moving on metric grids causes some small numerical errors to accumulate.

However, this misalignement problem cannot be fixed from the position and size menu, because the number of decimal digits shown here is too limited to show any difference.

Interestingly, the problem cannot be corrected by merely retyping the coordinate, but only changing the coordinate and changing it back. For instance, if the coordinate says 13.50, retyping 13.50 does not clear the extra decimal digits that are not shown. However, typing 13.60, applying this new value and then typing 13.50 and applying back this value does.
Comment 1 Florian Reisinger 2012-01-21 09:34:54 UTC
Could you please make a testcase for this ( A Draw document with the different problems [one-per-slide] )
After that, please mark as UNCONFIRMED again
Comment 2 Florian Reisinger 2012-08-14 14:03:46 UTC Comment hidden (obsolete)
Comment 3 Florian Reisinger 2012-08-14 14:04:42 UTC Comment hidden (obsolete)
Comment 4 Florian Reisinger 2012-08-14 14:09:11 UTC Comment hidden (obsolete)
Comment 5 Florian Reisinger 2012-08-14 14:11:12 UTC Comment hidden (obsolete)
Comment 6 Regina Henschel 2015-11-19 19:10:23 UTC
The internal precision of Draw is 1/100 mm. But the spin fields in the position & size dialog round to 2 decimal places. So it is impossible to enter and to see a value in its maximal possible precision. Therefore the request is, that the spin fields should allow at least as much decimal places as needed in the current unit to reflect the precision of 1/100 mm.
Comment 7 Heiko Tietze 2016-06-22 08:02:55 UTC
It happens sometimes that I don't want to deal with cm but the input has no flexibility to switch to px for instance. If we make it flexible the exact value would be up to the unit rather than bothering everybody with digits for µm precision.
Comment 8 sergio.callegari 2016-06-22 08:15:04 UTC
That can be a good idea.

However, note that when one sets a grid with some grid step in mm or cm, what he wants is really to be able to specify things to stay on the grid, which may need assuring that the decimal digits are OK. E.g., one can now have two items both at "10.00 cm", then add a connector between them and see that it is skewed, possibly because one object is actually at 10.00399 and the other one at 10.00101 cm.
Comment 9 Heiko Tietze 2016-06-22 08:28:55 UTC
(In reply to sergio.callegari from comment #8)
> ...possibly because one object is actually at 10.00399 and
> the other one at 10.00101 cm.

Those numbers are what I'm afraid of. There are very rare situations when a precision like this is needed (with the given units).
Comment 10 sergio.callegari 2016-06-22 09:53:17 UTC
In fact, what typically happens is that they come out as a side effect of some other action (e.g. cut and paste, distribute objects). Most of the time, what one would like to do is not setting all the decimal digits to any arbitrary value, but being able to set the least significant digits to zero. A minor exception is if one needs to divide some space in parts, creating fractions that result in periodic decimal numbers.

My feeling is that all these situations could be solved by having LibO show only a limited number of digits (output), but taking an arbitrary number of digits when one enters a quantity (input). This would let you assure that the least significant digits can always be correctly reset or set to any value.
Comment 11 Heiko Tietze 2017-01-23 13:30:57 UTC
Added a mockup to bug 72662 with the idea to have a dedicated edit mode. For example. when the control shows 3.14 pt and Benjamin clicks the number it could show the exact value like 3.14123 (without pt). If a precision above a certain decimal place is needed, he would have to switch to millimeter (less precise however).
Comment 12 Lionel Elie Mamane 2017-01-27 07:13:08 UTC
There was a discussion in December 2014 about approx the same issue in Base (report builder). There, with advice from UX team, it was decided to forcibly round to 10^-4 m (two decimal digits in cm) rather than display full precision. See bug 43556.

If it is changed to display full precision in Draw, it should probably be changed also in Base, for consistency.
Comment 13 Heiko Tietze 2017-01-27 09:31:40 UTC
(In reply to Lionel Elie Mamane from comment #12)
> There was a discussion in December 2014 about approx the same issue in Base
> (report builder). There, with advice from UX team, it was decided to
> forcibly round to 10^-4 m (two decimal digits in cm) rather than display
> full precision. See bug 43556.
> 
> If it is changed to display full precision in Draw, it should probably be
> changed also in Base, for consistency.

Thanks for the link, don't remember this decision. 

How I understand the request is to rather have a variable precision for the input. And somehow I also imagine a innovative visualization if the value has more digits.
Comment 14 sergio.callegari 2017-01-27 14:41:57 UTC
Is the base case comparable? Asking as I do not use base...

Is there a similar need as in (technical) drawing to

- get elements from some library (can be another drawing, can be gallery)
- link them using connectors
- be sure that connectors look OK (no 1 pixel step here and there)
Comment 15 V Stuart Foote 2017-07-05 19:38:50 UTC
*** Bug 108975 has been marked as a duplicate of this bug. ***
Comment 16 Eyal Rozenberg 2017-07-05 21:58:56 UTC
Coming from the recent dupe bug, I suggest this bug's name be changed from "probably" to "definitely". 

Just for comparison - remember that scanners typically support 2400 DPI resolution if not higher, which means 1 pixel is ~10^-6m = 0.001 cm. No reason why we should not be able to position content on a page at this resolution.

(In reply to Lionel Elie Mamane from comment #12)
> There, with advice from UX team, it was decided to
> forcibly round to 10^-4 m (two decimal digits in cm) rather than display
> full precision.

With due respect to UX considerations - at the very least there should be an option controlling this. It is not reasonable to cripple an app just to make the fractional digits slightly less confusing to newbies.

I understand that some underlying infrastructure is limited to 10^-5 meter increments, and the UX people might want to hide some semi-incoherent rounding artifacts at that resolution. If that's the case, then it's the underlying representation which should be made to use higher resolution.
Comment 17 Eyal Rozenberg 2018-10-12 19:25:04 UTC
I hope the CC'ed users will agree that this should be considered a bug rather than a suggested enhancement.
Comment 18 Heiko Tietze 2018-10-28 11:11:37 UTC
Removing needsUXEval. Comments are towards treating the issue as bug but I'd prefer a more flexible solution as outlined in c7 and c11. Could be an interesting GSoC project.
Comment 19 Eyal Rozenberg 2018-10-28 11:33:09 UTC
(In reply to Heiko Tietze from comment #18)

I'm certainly for a more comprehensive solution - but that looks like not-a-small-amount of work; and there would definitely be some arguing about the specifics of the UI control (I know I have some reservations about the mockup).

But in the mean time, being stuck with .01 cm resolution means that it's essentially impossible to straighten lines with one endpoint connected; or to do proper alignment + sizing etc. So, we _are_ taling a bug - which could and should have a quick fix before a comprehensive solution is put in place: Increase the number of digits in the control by 1. Or almost as easy a fix: Make the number of digits configurable, keeping the current default. When a comprehensive solution is introduced, that preference might just go away.


I'll also say that I am sure that the UX people have not considered the problems brought up here, and that the "only two decimal digits" decision was taken with a mind to make the control easier to use.
Comment 20 Heiko Tietze 2018-10-28 11:39:04 UTC
(In reply to Eyal Rozenberg from comment #19)
> But in the mean time, being stuck with .01 cm resolution...

You can switch to mm or pixels per Tools > Options > Draw > General > Unit of measurement (also available in other modules).
Comment 21 sergio.callegari 2018-10-28 15:44:33 UTC
As the original reporter of the bug, I'd like to note that while switching to mm is a partial not too uncomfortable solution, switching to pixels, which are generally not a decimal fraction of the user grid, is not something that the user can be expected to do unless for some reasons he is working in pixels from the very beginning.
Comment 22 Thomas Lendo 2019-06-09 08:22:15 UTC
*** Bug 67232 has been marked as a duplicate of this bug. ***