Created attachment 91122 [details] test document with a small rectangle The «Position and size» dialogue in LibreOffice Draw 4.2 can not shows size less than 10 mm in centimeters or millimeters units. It shows 1.00 cm or 10.00 mm for such objects Steps to reproduce: 1. Start Libre Office Draw. 2 Check that you use centimeters or millimeters length units (Tools -> Options -> LibreOffice Draw -> General -> Unit of measurement). 3 Draw a rectangle with sizes less than 10 mm. 4 Select the rectangle 5 Open «Position and size» dialogue (Format -> Position and size) Current behavior: Width and Height fields show 1.00cm (or 10.00mm) Expected behavior: The fields should contain correct sizes of the object. If you copy the object into LibreOffice Writer document and open «Position and size» dialogue there, it shows correct sizes. I met the problem in LibreOffice 4.2beta2 and 4.2.0.1 on Debian testing (“Jessie”) in VirtualBox. LibreOffice 4.1.2.3 from Debian 7 (“Wheezy”) backports and 4.1.3.2 on Windows7 work without the problem. I attach a test document with a small rectangle and a sceenshot with incorrect width and height. Operating System: Debian Version: 4.2.0.1 rc Last worked in: 4.1.3.2 release
Created attachment 91123 [details] a sceenshot with incorrect width and height
I see the error too on Windows 7 with 4.3.0.0.alpha0+ Build ID: a14cfd3d77104aee3e3c3d981a135161295197df TinderBox: Win-x86@47-TDF, Branch:master, Time: 2013-12-02_04:42:23 You cannot enter a smaller value than 1,00 in the height or width field. Only the "Position and Size" dialog (key F4) is affected, the dialog in the side bar works well and the display in the status bar is correct too.
I also see this in LibO 4.2.0 release. Issue is severe. It is not just that the width and height of small objects is displayed incorrectly. Big issue is that one /cannot enter/ widths or heights smaller than 1 cm! 1. Open libreoffice draw or impress 2. Draw a little object (e.g. a 2 mm x 3 mm rectangle) 3. Select object, right click and select 'position and size' to open position and size dialog 4. Note that object width is 1 and object height is 1 cm 5. Try to use the little arrows on the side of the boxes used to enter width and height. Note that it is impossible to get any number smaller than 1 cm 6. Try to enter a number using the keyboard. Note that any quantity smaller than 1 cm becomes 1 cm. Marked as regression since this was evidently OK before LibO 4.2. Consider rising priority. This is most likely an easy fix, but as is it makes LibO 4.2 not acceptable for any drawing requiring some precision.
LibO 4.1.5 is last working version
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'.
*** Bug 74946 has been marked as a duplicate of this bug. ***
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7c7bddc9bb22088110544343e41cc185c615ab28 fdo#72967 Draw position size tab - min size is 0 not 1 (mm) The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
1) Can the target be set to 4.2.1 too? 2) From the patch, I guess that all the other minor annoyances with 'metric' mode are independent from this issue. If someone can confirm, I'll file proper bug for them.
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9416c973d6749c3f7476b55bb91a4ac222a914b1&h=libreoffice-4-2 fdo#72967 Draw position size tab - min size is 0 not 1 (mm) It will be available in LibreOffice 4.2.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "libreoffice-4-2-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5d767fe36660384167697c697cbc94c58cf42f1a&h=libreoffice-4-2-1 fdo#72967 Draw position size tab - min size is 0 not 1 (mm) It will be available already in LibreOffice 4.2.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thanks for targeting 4.2.1 for the fix!
(In reply to comment #11) > Thanks for targeting 4.2.1 for the fix! Sure, it is a trivial fix for quite an annoyance. :) Can you file a separate bugs for the other issues that you found? Thanks, Tomaž
correcting target, since 4.2.1.1 is 4.2.1 release
I've just tried the 2014-2-22 daily from http://dev-builds.libreoffice.org/daily/libreoffice-4-2/Win-x86@42/2014-02-22_23.03.29/and the bug is still present there. Am I looking in the right place for the build that has the fix in it? On 21 February 2014 11:02, <bugzilla-daemon@freedesktop.org> wrote: > Michael Stahl <mstahl@redhat.com> changed bug 72967<https://bugs.freedesktop.org/show_bug.cgi?id=72967> > What Removed Added Whiteboard BSA PossibleRegression target:4.3.0 > target:4.2.1 BSA target:4.3.0 target:4.2.2 CC mstahl@redhat.com > Keywords regression > > *Comment # 13 <https://bugs.freedesktop.org/show_bug.cgi?id=72967#c13> > on bug 72967 <https://bugs.freedesktop.org/show_bug.cgi?id=72967> from > Michael Stahl <mstahl@redhat.com> * > > correcting target, since 4.2.1.1 is 4.2.1 release > > ------------------------------ > You are receiving this mail because: > > - You are on the CC list for the bug. > >
I installed the final version of 4.2.1 and it doesn't have the fix.. looks like I was too late. However the daily build you are trying should have this fix.
The latest daily build doesn't, I'm afraid. On 23 February 2014 19:25, <bugzilla-daemon@freedesktop.org> wrote: > *Comment # 15 <https://bugs.freedesktop.org/show_bug.cgi?id=72967#c15> > on bug 72967 <https://bugs.freedesktop.org/show_bug.cgi?id=72967> from > Tomaz Vajngerl <quikee@gmail.com> * > > I installed the final version of 4.2.1 and it doesn't have the fix.. looks like > I was too late. > > However the daily build you are trying should have this fix. > > ------------------------------ > You are receiving this mail because: > > - You are on the CC list for the bug. > >
I have tried to reproduce the bug with LibreOffice draw Version: 4.2.3.0.0+ Build ID: 166e2775d80b7e45ab258a4175d7b9e8a15a5dba TinderBox: Win-x86@42, Branch:libreoffice-4-2, Time: 2014-02-26_05:31:19 using wine and Version: 4.3.0.0.alpha0+ Build ID: db0222881be20744c071be451d77a7dc4a0dbb56 TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-02-21_10:31:05 on Debian Jessie But I can not reproduce the problem. Everything works fine. Mark, can you explain step-by-step what do you do?
Marking as fixed.
Now works for me. Got confused with the daily build not deleting the existing one. Thanks.
*** Bug 75981 has been marked as a duplicate of this bug. ***