Using attachment 131240 [details] from bug 83734#c6, the first image has a very high dpi count, but very small dimensions. However, in the properties the original size is now listed with as 1.00cm X 1.00cm instead of a more accurate 0.52 X 0.39 cm. This was caused by commit 14cb677a4325ac3e4e150f10a62f15e744093bf4 in LO 7.0 Author: Caolán McNamara Fri Feb 14 15:31:59 2020 +0000 remove MetricField use from cui The second image shows why this is a problem. The cropping numbers are based on the original size, and so a cropping of 0.18cm appears as if 18% of the image is being cropped out, when in fact it is closer to 30%. So without valid original image size values, it is just guesswork to figure out the numbers required to get the cropping that you want.
Created attachment 158373 [details] screenshot
Reproduced in Version: 7.0.0.0.alpha0+ Build ID: c57d6d39c80844c9d4c6bfed85cc151e52a67b34 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded
I imagine, from Xisco screenshot, we're talking about the crop tabpage
(In reply to Caolán McNamara from comment #3) > I imagine, from Xisco screenshot, we're talking about the crop tabpage Correct.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1e4e57afb50f25b5b7c4f24b3fb4d96c71e25b92 tdf#131111 we want a min of 0 not 1 for this formatting spinbox It will be available in 7.0.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.
an incorrect min of 1 was involved there, should be ok now
Thanks Caolán