Created attachment 177540 [details] CG72-Chapter-14-CN.odt Steps to Reproduce: 1. Open the attached test ODT file. Current Result: There is a big bottom margin for the image frame. I find no way to remove the margin. Tools > Upate does not work either. Expected Result: The bottom margin should be zero, as per settings in the frame property. Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: be30c734bf420f9dd890906c84d2b4460385a2ba CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: zh-CN (zh_CN.UTF-8); UI: zh-CN Build Platform: Fedora34@X64, Branch:master, bibisect-linux-64-7.4-CN Calc: threaded Also in 7.2.4.1 release.
Also in 6.0.0 oldest
Open the attached file: - Select the frame - Choose menu Format - Frame and Object - Properties - Change Position - Vertical from "From bottom" to "Top". - OK - Add and delete a new paragraph in the upper part of the document Actual results: There is no more extra space below the frame. Maybe the bug is that the space does not update automatically.
Forget to share: Version: 7.1.8.1 / LibreOffice Community Build ID: e1f30c802c3269a1d052614453f260e49458c82c CPU threads: 1; OS: Linux 4.12; UI render: default; VCL: x11 Locale: es-MX (es_AR.UTF-8); UI: en-US Calc: threaded
(In reply to LeroyG from comment #2) > Open the attached file: > > - Select the frame > - Choose menu Format - Frame and Object - Properties > - Change Position - Vertical from "From bottom" to "Top". > - OK > - Add and delete a new paragraph in the upper part of the document > > Actual results: > There is no more extra space below the frame. > > Maybe the bug is that the space does not update automatically. Bisected this with linux-64-5.4 to https://git.libreoffice.org/core/commit/63399341002c8a88ab58add99707fbef24210576 tdf#104640, tdf#108469: Insert image where the cursor is
Please retest, the frame is exactly the size of the image + the caption. Version: 24.8.2.1 (X86_64) / LibreOffice Community Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13 CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
(In reply to BogdanB from comment #5) > Please retest, the frame is exactly the size of the image + the caption. It's not about frame size, but frame margin, how it pushes away the stuff outside of it. Still the same. Arch Linux 64-bit Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 40beeb144a00c9725cde4239c251f67c658d31a8 CPU threads: 8; OS: Linux 6.10; UI render: default; VCL: kf6 (cairo+wayland) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded Built on 6 October 2024
I know how to make that disappear and also how to increase: Select the frame, not the image, and is: - drag up to increase - drag down to decrease See the video.
Created attachment 196944 [details] video testing the bug
A way to test what is changing is to see the source of the file, drag up and save, and now again see the source of the file.
<text:p text:style-name="Figure"> <draw:frame draw:style-name="fr1" draw:name="Frame435" text:anchor-type="as-char" svg:y="-11.361cm" svg:width="12.019cm" draw:z-index="0"> <draw:text-box fo:min-height="9.555cm"> <text:p text:style-name="Figure"> <draw:frame draw:style-name="fr2" draw:name="图像13" text:anchor-type="as-char" svg:width="10.603cm" svg:height="8.474cm" draw:z-index="1"> <draw:image xlink:href="Pictures/1000000100000247000001D2DD8C6419EE6A0FF7.png" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad" draw:mime-type="image/png"/> </draw:frame> </text:p> <text:p text:style-name="P5"> 图 <text:sequence text:ref-name="refFigure14" text:name="Figure" text:formula="ooow:Figure+1" style:num-format="1">1</text:sequence> : <text:span text:style-name="T55">公式选项</text:span> </text:p> </draw:text-box> </draw:frame> </text:p> After the change <text:p text:style-name="Figure"> <draw:frame draw:style-name="fr1" draw:name="Frame435" text:anchor-type="as-char" svg:y="-9.543cm" svg:width="12.019cm" draw:z-index="0"> <draw:text-box fo:min-height="9.555cm"> <text:p text:style-name="Figure"> <draw:frame draw:style-name="fr2" draw:name="图像13" text:anchor-type="as-char" svg:width="10.603cm" svg:height="8.474cm" draw:z-index="1"> <draw:image xlink:href="Pictures/1000000100000247000001D248A076D3.png" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad" draw:mime-type="image/png"/> </draw:frame> </text:p> <text:p text:style-name="P3"> 图 <text:sequence text:ref-name="refFigure0" text:name="Figure" text:formula="ooow:Figure+1" style:num-format="1">1</text:sequence> : <text:span text:style-name="T3">公式选项</text:span> </text:p> </draw:text-box> </draw:frame> </text:p> Here's a comparison: Positioning (SVG Y-coordinate): Before the change: svg:y="-11.361cm" After the change: svg:y="-9.543cm" The vertical positioning of the frame has changed, meaning the image is moved slightly up after the change. Image Source: Before the change: The image is linked as 1000000100000247000001D2DD8C6419EE6A0FF7.png. After the change: The image is linked as 1000000100000247000001D248A076D3.png. The image file itself has been changed between the two paragraphs. Text Style Names: Before the change: The text style for the paragraph containing the sequence and description is P5, and the span is styled as T55. After the change: The text style for the same content is now P3, and the span is styled as T3. Different style names are applied in the second version, likely reflecting different formatting settings.
The distance is not produced by the frame margin but by the position of the frame. Go to "Position and Size" tab of the "Properties" dialog of the frame and set the vertical position to 0. You might also try a different type of the vertical position.
(In reply to Regina Henschel from comment #11) > The distance is not produced by the frame margin but by the position of the > frame. Go to "Position and Size" tab of the "Properties" dialog of the frame > and set the vertical position to 0. You might also try a different type of > the vertical position. Should we close as notabug? Is it a regression after all?
As the value is that way in the file and thus it is rendered as the file describes, I see no bug here and therefore no regression. As long as we do not know, how the value comes into the file, we cannot decide whether that has been due to a bug. So I would close the bug here as 'notabug'.
Thanks.