Description: LibreOffice Draw and Writer use a native resolution of 0.01 millimeters. Fresh installation. Metrics Measurement Unit centimetre will lock to 2 decimal centimeters in picture resize. This example 100.03 mm width and 4.81 mm height, will become: 9.980 cm and 0.480 cm, which is wrong. I have changed it to a width of 10cm, but it will have height locked at 0.480, this gives the problem of not being able to get around 10cm, but it will always be much more off. Is the only solution to give the option of Measurement Unit centimetre with 3 decimals? Steps to Reproduce: 1. Take a picture with a large width and low height 2. With metrics Measurement Unit millimetre resize to a given width, but "keep ratio" locked and it will try to fit it with the 2 decimals low height. 3. Now change to metrics Measurement Unit centimetre, select original size and resize to the same given width, but "keep ratio" locked and it will again try to fit it with the 2 decimals low height. Actual Results: The width of the picture is noticeably different with between having metrics Measurement Unit millimetre and centimetre Expected Results: I'm expecting the "keep ratio" to adhere to LibreOffice native resolution of 0.01 millimeters and actually give me the right width and scale the height with only showing a rounded value, not actively locking to the rounded value. Reproducible: Always User Profile Reset: No Additional Info: If LibreOffice really use a native resolution of 0.01 millimeters, then please give me the options to have this resolution also when displaying other metrics and only show me rounded values. I know what my input is, but ti's being overwritten by a different resolution.
Created attachment 201103 [details] Example file 1. Open the attached file 2. Select the shape 3. Press F4 / Open shape properties 4. Position and size tab 5. Check lock ratio 6. Reduce the width by pressing arrow down (keyboard) 10 times. So decreasing width to 39 cm. Width becomes 3,89 cm 7. Increase the width by pressing arrow up (keyboard 10 times). Height becomes 3,98cm
Also in Version: 7.5.0.3 (X86_64) / LibreOffice Community Build ID: c21113d003cd3efa8c53188764377a8272d9d6de CPU threads: 8; OS: Mac OS X 14.7.4; UI render: Skia/Metal; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded and in Version: 7.0.0.3 Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
Already in OpenOffice 2.2.0
@Regina, Any clue what's going on here?
(In reply to Telesto from comment #4) > @Regina, > Any clue what's going on here? No, but it seems to be only a problem in Writer not in Draw.
But also in LibreOffice Calc
FWIW: I'm starting to question if I missed the point of this bug. And lacking insight if this being the result of 1 root cause. Or multiple issue being stacked upon each other. A) Certain value's not being allowed as input bug 166877 B) Keep ratio, not keeping ratio (comment 1) and bug 158535 A/B could be caused by different internal measurement (TWIPS?). Where in case B cumulation of rounding errors occur. This bug is apparently about acting the width of the picture being noticeably different with between having metrics Measurement Unit millimetre and centimetre
While I'm not commenting on a specific bug itself. I would think the lock ratio should have: - Ratio to be some floating point precision, not related to Metrics Measurement Units. - The specified/input width or height, only one not both, to guide the needed size. This is important when aligning an combining either horizontal or vertical. - The not specified/input width or height, so the other, to follow the needed size from above. This resulting value follows the lowest possible unit in the app and should not be related to Metrics Measurement Units. Displaying a rounded value is fine. The fact that the menu locks ratio and rounds each side reminds me of certain older menus from other apps, where you could lock on width/height and the size would gradually become smaller/bigger width each click in width/height. The reason was it was constantly updating and trying to round.
Comment from Mike Kaganski: bug 166877 comment 3 The sizes are stored internally as whole twips (twentieths of a point = 1/1440 in). That is about 0.0176 mm (1.76 of 1/100th of mm), so there is no way to represent any given size in hundredths of mm. It could only be resolved by increasing the overall internal resolution (preferable to EMUs). See also bug 138109.
I'm on windows 11 24h2 and an Irfanview selection of about 1334 x 855 pixels is copied to clipboard. The pixel to mm relation is not correct since it wasn't that exact picture, but just another similar, but I noted the exact changes after pasting in Calc below. Pasted directly in Calc it becomes about: w367.29 mm x h224.17 mm (as noted not that exact same pixel relation) If you select "Original Size" it becomes exactly: w352.94 mm x h223.30 mm It also changes aspect ratio visibly, which probably is a known bug. I then "Undo" the "Original Size" and it's still: w367.29 mm x h224.17 mm (looks normal) Then when "Saved", "Closed" and "Opened" again it's still: w367.29 mm x h224.17 mm (looks normal) Of note is, cropped images will have changed/offset vertical crops now, which probably is a known bug. If you then select "original size" it becomes exactly: w470.53 mm h297.69 mm (looks normal) The interesting part here for me, was that the image becomes scaled bigger from "Original Size" after saving. Not sure if that is related to the above mentioned native resolution being applied to the clipboard pasted image after saving.
(In reply to Kristian Knudsen from comment #10) > If you select "Original Size" it becomes exactly: w352.94 mm x h223.30 mm > It also changes aspect ratio visibly, which probably is a known bug. Not that I'm aware of; now it is: bug 166920 > The interesting part here for me, was that the image becomes scaled bigger > from "Original Size" after saving. Appears to be side-effect of the broken aspect ratio. So a variant of bug 166920. Didn't test extensively, but it doesn't happen in 7.4.8 --- FWIW: it comes bit confusing having when testing various applications in one bug. The image handling in Writer being different for historical reason.
I think your problem is with Writer (didn't test draw) being due conversion between twips and mm as mentioned in comment 9. So there is no proper support for resolution of 0.01 millimeters in reality (if measure set to mm in setting); although the dialog suggesting otherwise. And the problem here being covered by bug 138109