Description: On page style margin setup when entering the margins value in cm (2.5cm) the value converted to points is way bigger and incorrect. If the value entered in mm (25mm) all works ok. Steps to Reproduce: 1.Format 2.Page Style 3.Enter margin value in cm Actual Results: Entering 2.5cm results 85pt. Entering 25mm results in 70pt Expected Results: Entering 2.5cm results 70pt. Entering 25mm results in 70pt Reproducible: Always User Profile Reset: No Additional Info: Covert correctly
Created attachment 203152 [details] Video of the issue
I consider this to be ok.In Tools - Options - LibreOffice Writer - General you choose your Measurement unit, in this case you have Point. So, whatever you introduce will be converted to points. If you want cm, choose Centimeter.
Reproduced. Version: 25.8.2.2 (X86_64) Build ID: d401f2107ccab8f924a8e2df40f573aab7605b6f CPU threads: 8; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: CL threaded Jumbo Version: 25.8.3.0.0+ (X86_64) / LibreOffice Community Build ID: 6b124070e695649bb1480b32a15acfa606ee9738 CPU threads: 8; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: CL threaded Jumbo Since 2.54 cm (25.4 mm) equals 72 pt, isn't it strange that 2.5 cm becomes 85 pt? I think it should normally be 70 pt or 71 pt.
I confirmed it in the following version, but I think this issue might occur in versions even older than this one. Version: 5.4.7.2 Build ID: c838ef25c16710f8838b1faec480ebba495259d0 CPU threads: 8; OS: Windows 6.2; UI render: GL; Locale: ja-JP (ja_JP); Calc: CL Note: It says Windows 6.2, but it's actually Windows 11.
(In reply to Takenori Yasuda from comment #3) > Reproduced. => NEW
I observed the behavior. It seems to convert units in the following steps: 1. Round the input value to the smallest unit of the target unit (0.01 cm, 1 pt, etc.). - e.g., 2.5 cm → 3 cm 2. Convert the unit with that value. - e.g., 3 cm → 1700.7... twip → 1701 twip → 85.05 pt 3. Round the result to the smallest unit. - e.g., 85.05 pt → 85 pt Note: The rounding method in step 3 is unclear from this observation. If it were rounding, 25 mm would become 71 pt, but it actually becomes 70 pt. Tested cases: - 25.4 mm -> 70 pt (expected result: 72 pt) - 25 mm -> 70 pt (expected result: 70.8... pt -> 71 pt) - 2.5 cm -> 85 pt (expected result: 70.8... pt -> 71 pt) - 0.555 in -> 72 pt (expected result: 39.9... pt -> 40 pt) - 0.555 in -> 1.42 cm (expected result: 1.409... cm -> 1.41 cm) - 0.5 in -> 72 pt (expected result: 36 pt) - 0.4 in -> 0 pt (expected result: 28.8 pt -> 29 pt) Note: The expected results here assume that the rounding method in step 3 is rounding to the nearest whole number. Tested with: Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 11c3d7bb03ab1daa8f14fff076987f65b7e36700 CPU threads: 8; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: CL threaded Jumbo
In 6.4.2.2 Entering 2.5cm results 85pt. Entering 25mm results in 71pt
I tested with this: - 25 mm -> 70 pt (expected result: 70.8... pt -> 71 pt) In 6.4.2.2 Entering 25mm results in 71pt good In 7.0.2.1 Entering 25mm results in 71pt good In 7.1.2.1 Entering 25mm results in 71pt good In 7.1.2.2 Entering 25mm results in 71pt good In 7.2.2.1 Entering 25mm results in 70pt bad In 7.4.2.3 Entering 25mm results in 70pt bad
I am getting this bogdan@bogdan-IdeaCentre-AIO-3-24ALC6:~/Documents/bibisect linux 64/linux-64-releases$ git bisect good && $(find -iname soffice) ddda540cd650adda337ee7eed67a83f56ccc66f7 is the first bad commit commit ddda540cd650adda337ee7eed67a83f56ccc66f7 Author: Xisco Fauli <xiscofauli@libreoffice.org> Date: Thu Nov 18 23:54:14 2021 +0100 libreoffice-7.2.0.0.alpha1 LibreOfficeDev_7.2.0.0.alpha1_Linux_x86-64_deb.tar.gz
2.54cm -> 2.5cm(rounded) -> 70.9pt 25.4mm -> 72.0pt 2.54cm -> 85pt 25.4mm -> 71pt bibisected with linux-43all and linux-41max commit 7ba10e2d317a53763e1aff55a85546bfdac12fc5 author Olivier Hallot <olivier.hallot@alta.org.br> Tue Feb 26 22:09:55 2013 -0300 Convert page format tab page to new widget UI adding CC: Olivier Hallot Please, take a look?
bibisected with win64-7.2 f4fb2751ed6f66bf11f9e6c70471d53f14513f68 is the first bad commit source cfff893b9c82843a90aac4ecdb3a3936721b74a0 commit cfff893b9c82843a90aac4ecdb3a3936721b74a0 author Mike Kaganski <mike.kaganski@collabora.com> Sat Feb 13 13:55:22 2021 +0300 Move unit conversion code to o3tl, and unify on that in more places This also allows to easily add more units, both of length and for other unit categories. The conversion for "Line" unit (312 twip) is questionable. Corresponding entries in aImplFactor in vcl/source/control/field.cxx were inconsistent (45/11 in; 10/13 pc; 156/10 pt). They were added without explanation in commit c85db626029fd8a5e0dfcb312937279df32339a0. I haven't found a spec of the unit (https://en.wikipedia.org/wiki/Line_(unit) is not specific). I used the definition based on "by pt", "by mm/100", "by char" (they all were consistent); "by pc" seems inverted; "by twip" was half as much. This accepted conversion makes unit test for tdf#79236 pass. *** adding CC: Mike Kaganski
(In reply to Saburo from comment #10) > 2.54cm -> 2.5cm(rounded) -> 70.9pt > 25.4mm -> 72.0pt > > 2.54cm -> 85pt > 25.4mm -> 71pt > bibisected with linux-43all and linux-41max Please write some better descriptions. Here: reading this several times, I wasn't able to understand what that text wanted to say; and only after testing in versions 4.0 and 4.1 myself, I realized that it was "before the identified change, the top two lines happened; after that, the two bottom lines started to happen". In comment #11, what was bisected is not mentioned at all (it was in fact the minor change mentioned in comment 8). Maybe the fact that comment 8 was by Bogdan, was the reason why I was assigned as "guilty" for this problem, which was *first of all* about 2.5cm, not about 25.4mm.
https://gerrit.libreoffice.org/c/core/+/192235 https://gerrit.libreoffice.org/c/core/+/192236
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/dd544837226d9af2a777c145f91972fd0b755587 tdf#168709: round double value instead of truncation It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/81c707a4aa897d2793aa3f40dd08295ab7e019c9 tdf#168709: set decimal digits for Page dialog's metric controls It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Actual Results in current master: Entering 2.5 cm results 70.9 pt. Entering 25 mm results in 70.9 pt Thanks, Mike. Quick fix. Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: dc33e6bbcd3132036eff1069834348ea67de8cee CPU threads: 16; OS: Linux 6.14; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-25-8": https://git.libreoffice.org/core/commit/bb821267b55541e515087b598054502ec450840b tdf#168709: round double value instead of truncation It will be available in 25.8.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-25-8": https://git.libreoffice.org/core/commit/4c9a19587ffe26606f7664ae6272767b20c32609 tdf#168709: set decimal digits for Page dialog's metric controls It will be available in 25.8.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.