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]
Margins are 2.00cm
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?
User Profile Reset: No
Version: 220.127.116.11.alpha0+ (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
I meant "inconsistent" between Writer and Draw.
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
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: 18.104.22.168.alpha0+ (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
Created attachment 164086 [details]
for easier explanation of STR
please take a look at the attached screenshot. I meant the items indicated in the screenshot are inconsistent.
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.
Created attachment 164119 [details]
Screenshot that shows three entries "normal"
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.
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  , and the SWPAGE_NORMAL_VALUE is defined as 1136 (twips)  .
(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.
With Stuart's comment 8 no further UX input is needed. Perhaps an easyhack, though I have no code pointer at hand.
*** Bug 137136 has been marked as a duplicate of this bug. ***
*** Bug 136994 has been marked as a duplicate of this bug. ***
*** Bug 148698 has been marked as a duplicate of this bug. ***