Bug 139868 - Anchor To Cell position drifts as file opened and re-saved over time
Summary: Anchor To Cell position drifts as file opened and re-saved over time
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.1.0.2 rc
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-01-23 19:21 UTC by jasonkres
Modified: 2021-12-02 17:06 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jasonkres 2021-01-23 19:21:12 UTC
Description:
As a worksheet is open and re-saved over time, controls that are anchored To Cell drift in position.

The problem occurs even if the control position is locked after initially setting the position.

The problem occurs even if the worksheet is protected after initially setting the position.

This can be simulated by repeated Save and Reload instead of closing the entire application repeatedly.

The problem is not limited to Push Button. For example, I reproduce with Rectangle Shape anchored to cell and positioned at X=2.00", Y=2.00", Width=2.00", Height=2.00". However, this requires many more repetitions of the save and reload before the X=2.01" can be seen than in the Steps to Reproduce for the Push Button.

NOTE: In case it matters, I am in en-US with Measurement Unit set to its default of Inch.

Workaround: Avoid Anchor To Cell. Use Anchor To Page instead.

Steps to Reproduce:
1. Open Calc. NOTE: In case it matters, I am in en-US with Measurement Unit set to its default of Inch.
2. View > Toolbars > Form Controls.
3. Add a Push Button to the sheet.
4. Right click the Push Button for Control Properties.
5. Set these properties:
     Anchor: To Cell
     Position X: 5 cm
     Position Y: 5 cm
     Width: 5 cm
     Height: 5 cm
6. File > Save. Enter a filename.
7. File > Reload.
8. Repeat the Save and Reload of the file at least 4 times.
9. Choose Design Mode and view properties of the control. It has drifted to Position X = 5.01 cm.


Actual Results:
X = 5.01 cm

Expected Results:
X = 5.00 cm


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Version: 7.1.0.2 (x64) / LibreOffice Community
Build ID: 53d68d29d90fd16448721a60aad68c28ff0809f5
CPU threads: 12; OS: Windows 10.0 Build 19041; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL
Comment 1 Regina Henschel 2021-01-23 22:58:22 UTC
The problem is not your locale or measurement unit, but the internal units. Size and position of the cells are in unit "Twips", with 1pt = 20 Twips. The unit for drawing objects is 1/100 mm. Both are integer. When a drawing object is anchored to cell, its absolute position (in 1/100 mm) has to be converted in an offset (in 1/100mm) from left-top corner of cell (Twips). So rounding errors are unavoidable.

Bug 138109 is related to these rounding errors.

Besides that there might be off-by-one errors because the 'size' of a rectangle can be including or excluding edge. In mathematics the length of [..[ is the same as for [..], but in an integer grid not.
Comment 2 jasonkres 2021-01-29 23:08:10 UTC
Note that the rounding doesn't seem to stabilize... the errors accumulate to the point that it is very noticeable on screen and in print on frequently opened and modified documents. In other words, it can grow to over a quarter of an inch off, etc. over time.
Comment 3 Buovjaga 2021-12-02 12:55:11 UTC
(In reply to Regina Henschel from comment #1)
> The problem is not your locale or measurement unit, but the internal units.
> Size and position of the cells are in unit "Twips", with 1pt = 20 Twips. The
> unit for drawing objects is 1/100 mm. Both are integer. When a drawing
> object is anchored to cell, its absolute position (in 1/100 mm) has to be
> converted in an offset (in 1/100mm) from left-top corner of cell (Twips). So
> rounding errors are unavoidable.
> 
> Bug 138109 is related to these rounding errors.

So should we leave this bug open or...?