Download it now!
Bug 72967 - EDITING, UI: REGRESSION: Incorrect size in «Position and size» dialogue for small objects
Summary: EDITING, UI: REGRESSION: Incorrect size in «Position and size» dialogue for s...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
4.2.0.1 rc
Hardware: Other All
: medium normal
Assignee: Tomaz Vajngerl
URL:
Whiteboard: BSA target:4.3.0 target:4.2.2
Keywords: regression
: 74946 75981 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-12-22 11:39 UTC by Alexandr
Modified: 2014-03-11 14:17 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
test document with a small rectangle (7.86 KB, application/vnd.oasis.opendocument.graphics)
2013-12-22 11:39 UTC, Alexandr
Details
a sceenshot with incorrect width and height (105.47 KB, image/png)
2013-12-22 11:40 UTC, Alexandr
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexandr 2013-12-22 11:39:11 UTC
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
Comment 1 Alexandr 2013-12-22 11:40:52 UTC
Created attachment 91123 [details]
a sceenshot with incorrect width and height
Comment 2 Regina Henschel 2013-12-22 14:57:38 UTC
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.
Comment 3 sergio.callegari 2014-02-13 23:47:14 UTC
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.
Comment 4 sergio.callegari 2014-02-13 23:56:50 UTC
LibO 4.1.5 is last working version
Comment 5 sergio.callegari 2014-02-15 11:18:04 UTC
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'.
Comment 6 Alexandr 2014-02-15 13:56:58 UTC
*** Bug 74946 has been marked as a duplicate of this bug. ***
Comment 7 Commit Notification 2014-02-15 14:37:32 UTC
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.
Comment 8 sergio.callegari 2014-02-15 14:41:03 UTC
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.
Comment 9 Commit Notification 2014-02-17 09:59:17 UTC
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.
Comment 10 Commit Notification 2014-02-17 17:58:12 UTC
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.
Comment 11 sergio.callegari 2014-02-18 09:06:50 UTC
Thanks for targeting 4.2.1 for the fix!
Comment 12 Tomaz Vajngerl 2014-02-18 09:52:50 UTC
(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ž
Comment 13 Michael Stahl (CIB) 2014-02-21 11:02:10 UTC
correcting target, since 4.2.1.1 is 4.2.1 release
Comment 14 Mark Ellse 2014-02-23 17:10:00 UTC
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.
>
>
Comment 15 Tomaz Vajngerl 2014-02-23 19:25:42 UTC
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.
Comment 16 Mark Ellse 2014-02-23 23:35:01 UTC
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.
>
>
Comment 17 Alexandr 2014-02-26 17:43:06 UTC
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?
Comment 18 Andras Timar 2014-02-27 10:42:56 UTC
Marking as fixed.
Comment 19 Mark Ellse 2014-03-04 13:36:35 UTC
Now works for me. Got confused with the daily build not deleting the existing one. Thanks.
Comment 20 Adolfo Jayme 2014-03-11 14:17:39 UTC
*** Bug 75981 has been marked as a duplicate of this bug. ***