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.
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
Dear bug submitter! Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs. To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem. Yours! Florian
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.
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.
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.
(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).
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.
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).
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.
(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.
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)
*** Bug 108975 has been marked as a duplicate of this bug. ***
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.
I hope the CC'ed users will agree that this should be considered a bug rather than a suggested enhancement.
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.
(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.
(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).
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.
*** Bug 67232 has been marked as a duplicate of this bug. ***
*** Bug 128272 has been marked as a duplicate of this bug. ***
Created attachment 155312 [details] Bug 128272 screenshot #1
Created attachment 155313 [details] Bug 128272 screenshot #2
I'm not sure this report is the same as Bug 128272 "Metric measurements rounded to imperial units". I've attached two screen-shots to illustrate... In screenshot #1, I draw a shape and in the "Position & Size" dialogue I explictly set it's width and height to 90.00mm and 120.00mm respectively. In screenshot #2, I de-select the object and re-select it. It's width and height have now changed to 89.92mm by 119.89mm. These new dimensions are actually the equivalent of 3.54 inches (the nearest 1/100th inch to 90mm) and 4.72 inches (the nearest 1/100th inch to 120mm). So there does seem to be some interaction between the measurement units in this case.
This issue sounds more like an enhancement... I believe the UX team should decide which direction to take first, allowing mm to be used, or accepting more decimals...
(In reply to Xisco Faulí from comment #27) > This issue sounds more like an enhancement... I believe the UX team should > decide which direction to take first, allowing mm to be used, or accepting > more decimals... Unfortunately as is, it leads to document corruption on changing measurement units, increasing decimal precision of the resolution displayed in the GUI (with correct rounding, rather than truncation switching units) is needed. Best accomplished by increasing resolution of the spin controls and attribute fields to hold the 10^-5m resolution--and when we either shift to floating point or 64-bit interger caluclations the native canvas resolution can be increased beyond the 1/100th mm (10^5m) Meanwhile the spin box controls need to resolve at the 1/100th mm resolution to prevent the misplaced/missized objects we have now.
So is this a separate issue to original bug 44267? Should bug 128272 be re-opened?
(In reply to Xisco Faulí from comment #27) > This issue sounds more like an enhancement... No no, it's a bug. If all of LO actually respected the two-decimal-digit limit, internally, maybe you could argue it was just an enhancement. But in fact, a lot of X, Y, width and height values are set with with sub .01-unit-resolution values. The inability to see them and to set them, and to revert to original values after you've made a change.
(In reply to Xisco Faulí from comment #27) > UX team should decide which direction to take first UX input was done in c18. Adding a third decimal point might improve the situation but not entirely. And I'm afraid it would be awkward to more users than it helps. So my preference is a full solution.
My apologies for not making this a full report. This issue of limited precision has bitten me repeatedly over the years. I frequently do technical drawings for publication, and Draw could be a great tool for this. However, the two-decimal-place resolution invariably becomes an exercise in frustration. I do not know if this is the cause, but often when making complex drawings where I repeatedly move, resize, or adjust things ends up with stuff getting a tiny bit out of alignment, resulting in vertical or horizontal lines being just a little bit off, and visible (I often do simplified electrical schematics). Or, I will do dimensioned drawings for woodworking. If you use inches, you need at least 3 decimal places, or you cannot represent odd increments of 1/8", 1/16", etc. This makes it unacceptable for woodworking, which is really a fairly low precision application for which draw would otherwise be great. While these can be done in a 2-D CAD tool, such a tool is both overkill (steep learning curve, many unused features, cumbersome interface) and underkill (very difficult to make freeform technical illustration, which is best when writing technical articles or technical documentation). Draw could really serve this space well. I would really like to see the ability to have more precision in draw. Thanks and regards, John
I agree that while “there are a very rare situations when a precision like this is needed”, it is still a good idea. However, the option to change decimal precision belongs under: Tools > Options > LibreOffice Draw > General Decimal Precision The proposal in Comment 11 to clutter every dialog box up with the option to change measurements is a bad idea and poor workaround. It does not directly solve the problem. And the additional visual noise, clutter, and wasted space does not make sense for such a rarely needed feature. CAD apps like SOLIDWORKS and FreeCAD both solved this problem by putting decimal precision under Tools > Options. This is how we should also handle this feature.
(In reply to Luke from comment #33) > I agree that while “there are a very rare situations when a precision like > this is needed” Actually, this occurs in common, frequent situations - at least when working with Draw or Impress. You want to align a shape with another one and you just can't do it by setting the position and size values of just one of the shapes, since no value quite fits. See also comment 32. > the option to change > decimal precision belongs under: > Tools > Options > LibreOffice Draw > General Decimal Precision That should be a helpful workaround. (I don't have a strong opinion on per-text-box unit selection, but considering the age of this bug.)
Khaled, following your closing of bug 103322, can you explain the path you see to a fix for this bug?
(In reply to Eyal Rozenberg from comment #35) > Khaled, following your closing of bug 103322, can you explain the path you > see to a fix for this bug? No idea, you need to ask however linked the two bugs. Bug 103322 is about subpixel glyph positioning, I see nothing related to glyphs or text here.
(In reply to خالد حسني from comment #36) > I see nothing related to glyphs or text here. Comment #6... Regina said the internal precision of Draw is 10^{-2} mm. floating-point coordinates would mean that changes as well. IIUC, you've now implemented fixed-point with a scale we can control somehow. Assuming that's the case - we can use higher precision by upping the scale. Or - am I misunderstanding?
(In reply to Eyal Rozenberg from comment #37) > (In reply to خالد حسني from comment #36) > > I see nothing related to glyphs or text here. > > Comment #6... Regina said the internal precision of Draw is 10^{-2} mm. > floating-point coordinates would mean that changes as well. IIUC, you've now > implemented fixed-point with a scale we can control somehow. Assuming that's > the case - we can use higher precision by upping the scale. Or - am I > misunderstanding? I haven’t implemented anything, it is all Caolán’s work and it is been going on for a while, e.g. bug 144862. This bug and bug 103322 are completely unrelated.