Calc > format cells > borders > padding: value is not round-tripped when synchronise is unchecked

[micdev42]

I am setting a value for cell padding, but when I inspect it later, it has changed slightly e.g. set to 0.5mm. then on later inspection it will be 0.49mm.

Steps to reproduce in LibreOffice Calc, 7.3.2.2 (x64) on Windows 10. UK

• I have my units set to millimetre
• open a new sheet; select all cells; Format Cells (Ctrl+1)
• Borders > Padding
• uncheck Synchronise
• set Left padding to 0.50mm
• press OK to save

What I expect to happen:

• open the Format Cells dialog and the left padding should be 0.50mm

What actually happens:

• the value is set to 0.49mm

It’s not just the Left padding: all paddings have the same issue. It seems to corrupt all values slightly e.g. 1.00 is changed to 1.01 etc.

This does not happen when Synchronise is checked: I can set values like 0.49 or 1.50 and they are round-tripped as expected.

[Hrbrgr]

The problem is always the same, whether synchronized or not. I suspect an internal calculation problem. Ultimately, everything is calculated in the computer with “zeros” and “ones”. The question would be with how many places is calculated.

---

If the result is too inaccurate for you (finally it concerns here 1/100 mm), you can write a function inquiry on Bugzilla.

[joshua4]

If there are 2540 1/100th mm per inch and only 1440 twips per inch, can you get to 1/100th mm anyway? It would seem that about 1.76/100 mm is about as narrowly as you can define a value if twips are lurking in the background. Not sure if they do, or not, in Calc.

[Hrbrgr]

Why can't I set my own height in rows?

As @Lupp mentioned, one of the units used in LibreOffice is mm/100. Another (actually, it’s the primary Calc unit) is twip (1/20 pt = 1/1440 in). The ugliness in LO is not only use of these units (we better used EMUs = 1/36 000 000 m = 1 / 914 400 in exactly), but also doing that inconsistently (UNO (and ODF mostly) uses mm/100s, internal model of Calc uses twips, they are converted right and left). And then there was tdf#101217, which naively hoped that showing more decimals would benefit peo…

[micdev42]

You are correct re. the Synchronise flag: the problem exists when checked and unchecked.
I agree it’s a minor irritation, but…
The real issue is that the software is not storing the values the user enters: it converts the UI entered value into some internal representation, then converts back for subsequent display. That’s just the wrong way for (any) software to work. You may want to consider how UI values are stored going forward.
Anyway, you can close this question of you like: I’ll live with it!

[mikekaganski]

@micdev42

The real issue is that the software is not storing the values the user enters

Heh, I imagine your surprise when you start using Calc for actual calculations…