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: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.0.1.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 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: 2026-01-07 00:03 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


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

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
Description:
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

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

https://opengrok.libreoffice.org/xref/core/sw/source/uibase/sidebar/PageMarginUtils.hxx?r=01d0032f#22
https://opengrok.libreoffice.org/xref/core/sw/source/uibase/sidebar/PageFormatPanel.cxx?r=ec11b733#PaperModifyMarginHdl

* description should be changed to 
Normal (2.00 cm)

BTW:
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: 7.1.0.0.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
Calc: CL
Comment 1 himajin100000 2020-08-09 10:33:00 UTC
>contradictory

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:

Version: 7.0.1.0.0+
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: 7.1.0.0.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
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:

https://git.libreoffice.org/core/commit/656513d15116a3c6feeadc6a3353a304e0b3ef2b

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. ***
Comment 15 QA Administrators 2025-12-30 03:13:47 UTC
Dear himajin100000,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug
Comment 16 Eek! A Bug. Kill it! 2026-01-07 00:03:17 UTC
First of all, you send me an email five or six years after I posted a bug report and do so with the false salutation: "Dear himajin100000@gmail.com". That is not me, so neither himajin100000 or I must be all the "dear" to you. Secondly, under My Bugs, my original posting is not even listed, nor does it appear in any of the See Also bugs lists. Thirdly, in the My Bugs list, all of them have been marked "Never email me about this bug", yet years later, you do anyway??? The reason I marked them as such is because of my frustration over the curt responses I got -- not to mention that none of the bugs were ever resolved, with the common refrain of "I cannot duplicate the bug" or "we are NOT going to fix it because it only affects 5% of users!!"

My original report of this bug dealt with the fact that the US Letter page style margins setting for the Normal (0.75") setting is incorrect. Even though this would seemingly be an easy fix, it will obviously never get addressed if the bug is not assigned to someone. Of course, the alternative I discovered is to use the Moderate Margin setting (which has the same, albeit correct, margin setting for the US Letter Size (8-1/2" x 11") for 0.75" margins). Not sure why there is a duplication, except in this case it is nice because of the error in the intuitive setting. It still "bugs" the hell out of me that I cannot use the proper setting and have to use an unspecific, nebulous setting such as Moderate.

Now it seems the error is also in the metric versions as well. How can you get all the other margin settings correct -- except one?

You also ask for additional help, but you have a long history of ignoring bug reports, so why would you expect users to provide that help years after the bug was first reported? Additionally, you want users to download the oldest version of the software to determine when the bug first occurred? That is irrelevant. And, do you really think users want to clutter up the registry and hard drives with multiple copies of the same software? The fact of the matter is, the bug is not in the other company's software that was based on the same original open source you used. I was going to learn C++ just to fix all these bugs I've discovered, but I hate OOP, and in particular the C++ and its ever growing plethora of libraries that make mastering the language difficult as hell.