Bug 135572 - Normalize page margins in sidebar (1.9 instead of 2.0cm)
Summary: Normalize page margins in sidebar (1.9 instead of 2.0cm)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
: 136994 137136 148698 (view as bug list)
Depends on:
Blocks: Sidebar-Page
  Show dependency treegraph
Reported: 2020-08-09 08:40 UTC by himajin100000
Modified: 2023-12-30 17:01 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:

for easier explanation of STR (66.11 KB, image/png)
2020-08-10 06:59 UTC, himajin100000
Screenshot that shows three entries "normal" (31.94 KB, image/png)
2020-08-10 15:18 UTC, Dieter
margins for "Normal (0.75")" preset in inches (112.25 KB, image/png)
2020-08-11 03:47 UTC, Kiyotaka Nishibori

Note You need to log in before you can comment on or make changes to this bug.
Description himajin100000 2020-08-09 08:40:11 UTC
see steps to reproduce

Steps to Reproduce:
1. Launch Writer
2. Show [Page] Sidebar
3. Set [Margins:] to [Normal (1.90 cm)]
4. from Main menu, select [Format]->[Page Style]

Actual Results:
Margins are 2.00cm

Expected Results:
Either of :
* Margins should be 1.90 cm
but please be noted that 
(1080 / (72*20)) * 2.54 = 1.905, already very close to 1.90
(1136 / (72*20)) * 2.54 = 2.0037

20 twips = 1pt
1 pt = 1/72 inch
1 inch = 2.54 cm 


* description should be changed to 
Normal (2.00 cm)

LibreOffice Draw has similar sidebar panel,
If I choose [Normal (2.54cm)] in the panel,
and see the dialog opened from [Page]-[Properties] in main menu
margins are 1.27, just the half of what is indicated value.

These look contradictory to me, but is this intentional?

Reproducible: Always

User Profile Reset: No

Additional Info:
Version: (x64)
Build ID: 7657fecbceb656d7745a0ae7674a733c722343d8
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: default; VCL: win
Locale: ja-JP (ja_JP); UI: en-US
Calc: CL
Comment 1 himajin100000 2020-08-09 10:33:00 UTC

I meant "inconsistent" between Writer and Draw.
Comment 2 Kiyotaka Nishibori 2020-08-10 02:37:52 UTC
This issue was reproduced also on following build:

Build ID: dc6093be8f016283880271bda72e8e0142b962a8
CPU threads: 8; OS: Linux 5.7; UI render: default; VCL: gtk3
Locale: ja-JP (ja_JP.UTF-8); UI: en-US
Calc: CL
Comment 3 Dieter 2020-08-10 06:46:06 UTC
Sorry, steps to reproduce are not clear to me. I've tried the follwoing steps

1. Open writer
2. Sidebar => Page tab
3. Default Page style => Modify
4. Change margins from 2 cm to 1,9 cm => O. K.
5. Main menu => Fomat => Page Style

Actual result: margins are 1,9 cm (as expected).

But perhaps I did something wrong?

Version: (x64)
Build ID: <buildversion>
CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: threaded
Comment 4 himajin100000 2020-08-10 06:59:42 UTC
Created attachment 164086 [details]
for easier explanation of STR
Comment 5 himajin100000 2020-08-10 07:00:41 UTC
please take a look at the attached screenshot. I meant the items indicated in the screenshot are inconsistent.
Comment 6 Dieter 2020-08-10 15:17:03 UTC
Thank you for screenshot. Now it's clear to me and I can confirm it.

I think it's easier just to change description in the sidebar. I also don' I understand, why three different setting are normal.

cc: Design-Team for decision about expected result.
Comment 7 Dieter 2020-08-10 15:18:10 UTC
Created attachment 164119 [details]
Screenshot that shows three entries "normal"
Comment 8 V Stuart Foote 2020-08-10 17:00:39 UTC
The "Normal" labeling came from old Margin spinbox controls when for bug 83830 they were first moved to the Sidebar ( https://gerrit.libreoffice.org/c/core/+/25520/ ) with:


The values had to be cleaned up to correctly handle locale '"' vs 'cm'.  But the 1.90 cm is actually the SWPAGE_NORMAL_VALUE of 1136 Twips, or 3/4"--these are just the static listbox values for the GUI provided in Twips and converted to either inch or cm, now in pageformatpanel.hrc 

And IIUC the shown Page style margin of 2.00 cm is coming from the A4 document template in use for the locale.

So, yes this is kind of a mess--moving between locales.
Comment 9 Kiyotaka Nishibori 2020-08-11 03:47:48 UTC
Created attachment 164143 [details]
margins for "Normal (0.75")" preset in inches

I doubt if SWPAGE_NORMAL_VALUE of 1136 twips is converted to 3/4" (0.75").

See the attachment. This is the screenshot  in case that measurement unit has been set to inch. As you see, when the Normal (0.75")  is selected for the Margins item in Side panel, the all margins are set to not 0.75" but 0.79" in Page Style dialog. 

All margins for Nomal075  are defined as SWPAGE_NORMAL_VALUE [1] [2], and the SWPAGE_NORMAL_VALUE is defined as 1136 (twips) [3] .

[1] https://opengrok.libreoffice.org/xref/core/sw/source/uibase/sidebar/PageMarginUtils.hxx?r=01d0032f#91
[2] https://opengrok.libreoffice.org/xref/core/sw/source/uibase/sidebar/PageMarginUtils.hxx?r=01d0032f#101
[3] https://opengrok.libreoffice.org/xref/core/sw/source/uibase/sidebar/PageMarginUtils.hxx?r=01d0032f#23
Comment 10 V Stuart Foote 2020-08-11 13:23:52 UTC
(In reply to Kiyotaka Nishibori from comment #9)
> Created attachment 164143 [details]
> margins for "Normal (0.75")" preset in inches
> I doubt if SWPAGE_NORMAL_VALUE of 1136 twips is converted to 3/4" (0.75").

Oops, /me embarrassed--should have done the math/conversions

   1136/1440 = 0.79  <==>  2.54 * 0.79 = 2.00

so the SWPAGE_NORMAL_VALUE of 1136 twips is the 2.00cm margin not 3/4" margin

The defaults mix metric and imperial measurements. Reading back through bug 109100 I see where I got crossed up in my recollection.
Comment 11 Heiko Tietze 2020-08-11 13:28:58 UTC
With Stuart's comment 8 no further UX input is needed. Perhaps an easyhack, though I have no code pointer at hand.
Comment 12 Heiko Tietze 2020-09-30 08:06:24 UTC
*** Bug 137136 has been marked as a duplicate of this bug. ***
Comment 13 Justin L 2021-01-26 08:53:21 UTC
*** Bug 136994 has been marked as a duplicate of this bug. ***
Comment 14 Heiko Tietze 2022-04-25 15:16:26 UTC
*** Bug 148698 has been marked as a duplicate of this bug. ***