https://bugs.freedesktop.org/show_bug.cgi?id=72967
--- Comment #5 from sergio.calleg...@gmail.com --- Unfixed in 4.2.1 RC 1. Please, consider reverting changes early when they cause regressions. Some more notes: 1) This does not seem to affect LibO when working in non-metric systems, which is probably the reason it went unnoticed. 2) When one dimension (e.g. height) is touched in 'position and size' dialog, the other (e.g. width) gets changed up to 1 cm when originally smaller, thus this bug also results in non asked and non wanted changes to drawings. Consider rising priority since the application may change drawings in ways that may be inconvenient to recover for some users. 3) There are a lot of rounding quirks when working with metric system. For instance, when one selects the tab space at 1.25 cm with 'cm' units and then moves to 'mm' he finds out that the tab space has in fact been set to 1.251 cm. Even worse, if you set the unit to 'mm', then you fix the tab space at 12.50 mm, this is accepted. However, if you then switch to 'cm' and immediately back to 'mm', you see that the tab space has become 12.51 mm again. Should I file another bug for this? 4) The up/down arrows used to increment position and size entries do not respect the user selected grid, but seem to use arbitrary increments. For instance, I see position changing in steps of 0.5 mm with unit set to 'mm', and 1 mm in 'cm' when the grid is at 1 mm. For some grid steps this means that the increment and decrement buttons can move objects off grid. This is very minor, but IMHO worth fixing. Should I file another bug for this? 5) The number of decimal digits used to show position and size seem to be arbitrary (2 with 'cm', 3 with 'km'). I realize that limiting to a few digits is convenient for display, but I cannot understand why for 'input' the extra digits get discarded. For instance, if I switch to cm and I enter 1.321 as an x position and then I move to mm, I expect to see 13.21, but I see 13.20, because my input was truncated to 2 decimal digits. The other way round, if I switch to mm and I enter 13.21, then I go back to cm and enter 1.32, when I go back to mm I discover that the position stayed at 13.21. Namely, my input has keept the previous stuff after the 2nd decimal digit instead of resetting it to 0. In other words, it seems harder than it should to get rid of the unshown decimals. All this may result in prints with minor misalignments that cause lines that should be perfectly horizontal or vertical to get ugly 'steps'. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
