Created attachment 183894 [details] demonstrating the states mentioned in the report
The default frame style for inserted images 'Grahics' has the vertical relation 'Top' to 'Entire paragraph area' (with value 0.00). After 'Insert Caption this is changed to 'Top' to 'Paragraph text area'. This induces a blank space between the top border of the caption frame and the 'Graphics' frame representing the image. Applying the same frame style now explicitly to the images remedies.
Confirmed on: Version: 7.4.2.3 / LibreOffice Community Build ID: 40(Build:3) CPU threads: 8; OS: Linux 5.19; UI render: default; VCL: x11 Locale: fr-FR (fr_FR.UTF-8); UI: en-US Ubuntu package version: 1:7.4.2~rc3-0ubuntu1 Calc: threaded The Graphics frame style applied to the pic seems to get an additional layer of parameters that creates the space above the pic. Reapplying that same Graphics style removes it.
To keep the caption with the graphic a frame is needed. And these two styles don't match well and lack on some important attributes such as anchor settings, see bug 32484. But let's handle this with bug Bug 32485 Btw. the style "Frame" is defined with black borders which are not applied resp. overwritten with the automatic insertion. Just another inconsistency. *** This bug has been marked as a duplicate of bug 32485 ***
(In reply to Heiko Tietze from comment #4) > To keep the caption with the graphic a frame is needed. ... Of course. > ... And these two styles > don't match well and lack on some important attributes such as anchor > settings, ... No longer correct for V 7.2 and higher. (See release notes). The default anchor type for 'Graphics' is now 'To paragraph' Also the default vertical relation ('Top', <none>, 'Entire paragraph area') is as needed/applicable. Concerning the 'Graphics' style the problem is that its original settings aren't actually applied. Changes are made to the specific object by the process of 'Insert Caption...'. Concerning the properties of the caption frame see below. > ...see bug 32484. > But let's handle this with bug Bug 32485 That old bug was "legacy" (inherited from OOo) and was reported 12 years ago. To handle this new report related to a situation changed with many respects since V3.3 as a duplicate might mean another 10 years of delay. Insofar: objection. BTW: The bug is fixed in Apache OpenOffice (tested with V 4.1.7). > > Btw. the style "Frame" is defined with black borders which are not applied > resp. overwritten with the automatic insertion. Just another inconsistency. Yes. That's bad. A frame style 'CaptionFrame' with appropriate settings is needed. Otherwise the style 'Frame' must be applied as it is. This at least wouldn't leave the user uninformed, and would motivate him (f/m) to define and assign an appropriate child style himself. META: Generally a process called via a special path (menu/shortcut/toolbar) should never apply a named style not actually appropriate with respect to the supposed needs. If a variant of the style is needed, it must be defined as a child. Only this way the user can edit that style and choose the settings she (m/f) thinks to be preferrable. (As far as I can see, this principle was regarded concerning paragraph styles.) > *** This bug has been marked as a duplicate of bug 32485 *** (not a good idea, imo)
(In reply to Wolfgang Jäger from comment #5) > > *** This bug has been marked as a duplicate of bug 32485 *** > (not a good idea, imo) Stéphane, your call.
Thank you Wolfgang and Heiko. As I understand it, the spacing issue above the captioned image is an annoying problem that could be fixed independently from the wider-ranging issue described in bug 32485 ("should properties even be modified / transfered at all?"). I would however close this bug as a duplicate of the existing Bug 147770, as it covers the issue of the space above the image. *** This bug has been marked as a duplicate of bug 147770 ***