Bug Hunting Session
Bug 43556 - EDITING report design: lengths & positions shown rounded -> hides information, leads to seemingly unexplainable behaviour
Summary: EDITING report design: lengths & positions shown rounded -> hides information...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
Master old -3.6
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:3.7.0 target:3.6.0.0.beta3 tar...
Keywords:
Depends on:
Blocks: mab3.5
  Show dependency treegraph
 
Reported: 2011-12-06 12:11 UTC by Lionel Elie Mamane
Modified: 2017-04-06 20:33 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Illustration (23.77 KB, image/svg+xml)
2011-12-06 12:11 UTC, Lionel Elie Mamane
Details
example document (28.38 KB, application/vnd.oasis.opendocument.database)
2011-12-08 00:53 UTC, Lionel Elie Mamane
Details
screenshot: control1 as shown in UI (27.33 KB, image/png)
2011-12-08 00:54 UTC, Lionel Elie Mamane
Details
screenshot: control2 as shown in UI (27.43 KB, image/png)
2011-12-08 00:54 UTC, Lionel Elie Mamane
Details
screenshot: generated report (17.24 KB, image/png)
2011-12-08 00:55 UTC, Lionel Elie Mamane
Details
screenshot: generated report: - edit (19.51 KB, image/png)
2011-12-08 00:57 UTC, Lionel Elie Mamane
Details
screenshot: generated report - optimal row height (34.97 KB, image/png)
2011-12-08 00:58 UTC, Lionel Elie Mamane
Details
screenshot: generated report - result (27.73 KB, image/png)
2011-12-08 01:00 UTC, Lionel Elie Mamane
Details
screenshot macro show real height step 1 (18.33 KB, image/png)
2011-12-08 01:00 UTC, Lionel Elie Mamane
Details
screenshot macro show real height step 2 (7.62 KB, image/png)
2011-12-08 01:01 UTC, Lionel Elie Mamane
Details
screenshot macro show real height step 3 - result detail section (1.87 KB, image/png)
2011-12-08 01:02 UTC, Lionel Elie Mamane
Details
screenshot macro show real height step 4 - result control1 (2.18 KB, image/png)
2011-12-08 01:02 UTC, Lionel Elie Mamane
Details
screenshot macro show real height step 5 - result control2 (2.24 KB, image/png)
2011-12-08 01:02 UTC, Lionel Elie Mamane
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lionel Elie Mamane 2011-12-06 12:11:19 UTC
Created attachment 54160 [details]
Illustration

In report design (edit) view, lenghts and positions of controls (width, height, PosX, PosY) are displayed with a precision of 10^-4 m (tenth of a millimeter), but are stored with a precision of 10^-5 m (hundreth of mm).

This may seem inconsequential (who cares about hundreths of a millimeter in print-out?), but has nasty consequences of report builder behaving in a seemingly inconsistent and unpredictable way. Take the situation in the illustration: In the Detail section, there are two controls, whose top is aligned. One has height 331 (hundredths of a mm), The other has height 330. But *both* are shown to have height 0.33cm in the properties dialog, so it looks like they have same height.

Now, generate the report from that. All looks well, because 0.01mm is basically invisible. But instead of one table row per data row (in the database), the table in the generated report has *two* rows per data row: One of height 0.33cm and one of height .001cm. Now, put the document in edit more (right-click and "edit" in contextual menu), select the whole table, right-click (contextual menu), choose row / height / optimal. Suddenly "phantom" empty rows appear between each row of data! That's extremely confusing to the user, since other reports don't do that.

It happened to me, I got the idea that maybe some controls had a different height and/or an offset PosY and that this was the problem. But I checked and double-chechked, they all had PosY=0 and height=0.33cm. Only when I got the idea to look at the properties through a Basic macro rather than through the UI did I understand the problem.


So I would advocate that we either forcfully round all lengths and positions to 10^-4 m precision or show the full 10^-5 precision in the properties dialog. Showing full precision seems the cleanest to me.
Comment 1 Zoltán Reizinger 2011-12-07 23:33:47 UTC
I can not reproduce it in LibO 3.4.4. Could you upload an example document?

Workaround, select all controls in a row, then you can edit their height, Y-position, width together.
Comment 2 Lionel Elie Mamane 2011-12-08 00:53:07 UTC
Created attachment 54219 [details]
example document
Comment 3 Lionel Elie Mamane 2011-12-08 00:54:06 UTC
Created attachment 54220 [details]
screenshot: control1 as shown in UI
Comment 4 Lionel Elie Mamane 2011-12-08 00:54:44 UTC
Created attachment 54221 [details]
screenshot: control2 as shown in UI
Comment 5 Lionel Elie Mamane 2011-12-08 00:55:58 UTC
Created attachment 54222 [details]
screenshot: generated report
Comment 6 Lionel Elie Mamane 2011-12-08 00:57:39 UTC
Created attachment 54223 [details]
screenshot: generated report: - edit
Comment 7 Lionel Elie Mamane 2011-12-08 00:58:42 UTC
Created attachment 54224 [details]
screenshot: generated report - optimal row height
Comment 8 Lionel Elie Mamane 2011-12-08 01:00:00 UTC
Created attachment 54225 [details]
screenshot: generated report - result

From user's point of view, phantom lines appeared.
Comment 9 Lionel Elie Mamane 2011-12-08 01:00:56 UTC
Created attachment 54226 [details]
screenshot macro show real height step 1
Comment 10 Lionel Elie Mamane 2011-12-08 01:01:26 UTC
Created attachment 54227 [details]
screenshot macro show real height step 2
Comment 11 Lionel Elie Mamane 2011-12-08 01:02:11 UTC
Created attachment 54228 [details]
screenshot macro show real height step 3 - result detail section
Comment 12 Lionel Elie Mamane 2011-12-08 01:02:28 UTC
Created attachment 54229 [details]
screenshot macro show real height step 4 - result control1
Comment 13 Lionel Elie Mamane 2011-12-08 01:02:54 UTC
Created attachment 54230 [details]
screenshot macro show real height step 5 - result control2
Comment 14 Lionel Elie Mamane 2011-12-08 01:06:52 UTC
(In reply to comment #1)

> Workaround, select all controls in a row, then you can edit their height,
> Y-position, width together.

Obviously, once one knows what the source of the problem is, the work-around is indeed easy. But as the source of the problem is hidden, it is quite hard to understand the source of the problem, and thus quite hard to get to the work-around overall.
Comment 15 Zoltán Reizinger 2011-12-08 02:49:33 UTC
I can reproduce it in LibO 3.4.4 under win7, with your example file.
Comment 16 Lionel Elie Mamane 2012-07-04 08:45:11 UTC
After discussion, it was decided to forcefully round all positions and dimensions to nearest 10^-4 m.
The main argument was consistency: All over LibreOffice, dimensions are shown in 10^-4 m (when using the metric system).
Comment 17 Not Assigned 2012-07-04 08:55:45 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8dd6a23b6b44902d1c1ae4e24360463ffcf1015d

fdo#43556 round pos&dim of report controls & sections to nearest 10^-4m
Comment 18 Not Assigned 2012-07-04 08:56:19 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=067a3e264797bd60117bea72db4877031af9805b&g=libreoffice-3-6

fdo#43556 round pos&dim of report controls & sections to nearest 10^-4m


It will be available in LibreOffice 3.6.
Comment 19 Not Assigned 2012-07-05 00:56:47 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "libreoffice-3-5":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=2c37b5ba27d5289b3ec5c0ad3273cdb7d7fa9848&g=libreoffice-3-5

fdo#43556 round pos&dim of report controls & sections to nearest 10^-4m


It will be available in LibreOffice 3.5.6.