When applying a caption, frame styles are not honoured. Steps to reproduce the issue: In a new Writer document, edit the "Graphics" frame style in order to add space below any inserted image. Insert two dummy paragraphs and between them insert an image. When the image is inserted, the spacing works as expected. Now, right click over the image and select "caption". Type any text and press enter. Expected behavior: The space set in the Graphics frame style keep a distance between the image and the caption. Result: The space below the image is "transferred" to the new external frame and no space is left between the image and the caption. Below the external frame a space NOT set by the user is inserted while the configured space below the image get lost. Notice: By re-applying the Graphics frame style to the image only, the space is recreated. Everything behave as if direct formatting were applied to both, Graphics and "external" frame style reverting the spacing settings introduced by the user. In fact, the frame that contains both image and caption is a "variation" of he "Frame" frame style, but with "direct formatting" applied on it: There is no way to control the default properties for that frame. This behavior goes against the whole idea of frame styles.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
The problem is present on 3.5 beta2.
Created attachment 79733 [details] Files (ODT/PDF/JPEG) for 4-step process outlining captioning. I am attaching a series of working examples and providing some further detail in order to better illustrate the point being made by the OP. This problem still occurs under v4.0.3.3 (Build ID: 0eaa50a932c8f2199a615e1eb30f7ac74279539). In summary, as indicated by the OP, the visual display of elements (after captioning) does not indicate the underlying XML frame style definitions. Hopefully the detail here is helpful. My attached example includes several files, which are relatively self-explanatory by their names. They indicate a 4-step process of: 1_ Two text paragraphs and the "Graphics" and "Frame" styles formatted as required (both with No Wrap, 18pt above/below for Graphics, 0pt above/below for Frame, both with width 100%, height Auto, and position Left/Top). 2_ A single graphic inserted between the two paragraphs (JPEG is included separately). 3_ The single graphic captioned via right-click > Caption... method i.e., graphic is enclosed in a text box. 4_ "Graphics" frame style is re-applied to graphic in text box. There is a PDF of each ODT for clarity. The following is an overview of the XML during critical stages of this process. Step 2 - Uncaptioned graphic When a graphic is inserted it is placed in a <draw:frame> element and given a corresponding <style:style> element (in content.xml), which in turn links to a <style:style> and <style:graphic-properties> element pair for the "Graphics" frame style (in styles.xml) where the fo:margin-top and fo:margin-bottom attributes are set. For example in the attached file 2_inserted_graphic.odt the XML appears thus: content.xml: <style:style style:name="fr1" style:family="graphic" style:parent-style-name="Graphics"> <style:graphic-properties style:vertical-pos="top" style:vertical-rel="paragraph-content" style:mirror="none" fo:clip="rect(0pt, 0pt, 0pt, 0pt)" draw:luminance="0%" draw:contrast="0%" draw:red="0%" draw:green="0%" draw:blue="0%" draw:gamma="100%" draw:color-inversion="false" draw:image-opacity="100%" draw:color-mode="standard"/> </style:style> <draw:frame draw:style-name="fr1" draw:name="graphics1" text:anchor-type="paragraph" svg:width="299.99pt" svg:height="150.01pt" draw:z-index="0"> <draw:image xlink:href="Pictures/1000000000000190000000C86E44B4CA.jpg" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/> </draw:frame> styles.xml: <style:style style:name="Graphics" style:family="graphic"> <style:graphic-properties svg:width="481.89pt" style:rel-width="100%" fo:min-height="1.16pt" text:anchor-type="paragraph" svg:x="0pt" svg:y="0pt" fo:margin-top="18pt" fo:margin-bottom="18pt" style:wrap="none" style:vertical-pos="top" style:vertical-rel="paragraph-content" style:horizontal-pos="left" style:horizontal-rel="paragraph"/> </style:style> Note the initial definition for above / below margins surrounding the graphic are handled via the "Graphics" frame style in styles.xml. This is expected and matches that in 1_text_only_edited_frame_styles.odt. Step 3 - Captioned graphic When a graphic is given a caption via the right-click > Caption... method an additional text box is added around the existing frame. The original <draw:frame> element is enclosed in a subsequent <draw:frame> and <draw:text-box> element pair, with the text-box linking to the "Frame" frame style in styles.xml. For example in the attached file 3_inserted_graphic_with_caption.odt the XML appears thus: content.xml: <style:style style:name="fr1" style:family="graphic" style:parent-style-name="Frame"> <style:graphic-properties fo:margin-top="18pt" fo:margin-bottom="18pt" style:vertical-pos="top" style:vertical-rel="paragraph-content" style:horizontal-pos="left" style:horizontal-rel="paragraph" fo:padding="0pt" fo:border="none"/> </style:style> <style:style style:name="fr2" style:family="graphic" style:parent-style-name="Graphics"> <style:graphic-properties fo:margin-left="0pt" fo:margin-right="0pt" fo:margin-top="0pt" fo:margin-bottom="0pt" style:run-through="foreground" style:wrap="none" style:vertical-pos="from-top" style:vertical-rel="paragraph-content" style:horizontal-pos="from-left" style:horizontal-rel="paragraph-content" fo:padding="0pt" fo:border="none" style:shadow="none" style:mirror="none" fo:clip="rect(0pt, 0pt, 0pt, 0pt)" draw:luminance="0%" draw:contrast="0%" draw:red="0%" draw:green="0%" draw:blue="0%" draw:gamma="100%" draw:color-inversion="false" draw:image-opacity="100%" draw:color-mode="standard"/> </style:style> <draw:frame draw:style-name="fr1" draw:name="Frame1" text:anchor-type="paragraph" svg:width="299.99pt" draw:z-index="0"> <draw:text-box fo:min-height="150.01pt"> <text:p text:style-name="Figure"> <draw:frame draw:style-name="fr2" draw:name="graphics1" text:anchor-type="paragraph" svg:x="0.11pt" svg:y="0.06pt" svg:width="299.99pt" style:rel-width="100%" svg:height="150.01pt" style:rel-height="scale" draw:z-index="1"> <draw:image xlink:href="Pictures/1000000000000190000000C86E44B4CA.jpg" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/> </draw:frame>Figure <text:sequence text:ref-name="refFigure0" text:name="Figure" text:formula="ooow:Figure+1" style:num-format="1">1</text:sequence>. Bar scene. </text:p> </draw:text-box> </draw:frame> style.xml: <style:style style:name="Graphics" style:family="graphic"> <style:graphic-properties svg:width="481.89pt" style:rel-width="100%" fo:min-height="1.16pt" text:anchor-type="paragraph" svg:x="0pt" svg:y="0pt" fo:margin-top="18pt" fo:margin-bottom="18pt" style:wrap="none" style:vertical-pos="top" style:vertical-rel="paragraph-content" style:horizontal-pos="left" style:horizontal-rel="paragraph"/> </style:style> <style:style style:name="Frame" style:family="graphic"> <style:graphic-properties svg:width="481.89pt" style:rel-width="100%" fo:min-height="9.75pt" text:anchor-type="paragraph" svg:x="0pt" svg:y="0pt" fo:margin-left="0pt" fo:margin-right="0pt" fo:margin-top="0pt" fo:margin-bottom="0pt" style:wrap="none" style:vertical-pos="top" style:vertical-rel="paragraph-content" style:horizontal-pos="left" style:horizontal-rel="paragraph-content" fo:padding="4.25pt" fo:border="0.06pt solid #000000"/> </style:style> As can been seen the inner graphics frame (style name "fr1" originally) has become "fr2" and the associated "Graphics" frame style in styles.xml has maintained the fo:margin-top and fo:margin-bottom settings ("18pt" in the example) as expected. Similarly the "Frame" frame style in styles.xml has maintained its fo:margin-top and fo:margin-bottom settings ("0pt" in the example). However the style:graphic-properties element for the "Frame" frame style in content.xml now also has fo:margin-top and fo:margin-bottom set to "18pt". As the OP mentions the spacing appears "transferred" from the graphic to the enclosing text box. Step 4 - Re-applied "Graphics" frame style Re-applying the "Graphics" frame style to the enclosed graphic brings back the space between the graphic and surrounding frame. The differences in content.xml and style.xml between 3_inserted_graphic_with_caption.odt and 4_inserted_graphic_with_caption_with_reapplied_style.odt are: content.xml: The <style:graphic-properties> element for the "fr2" (graphic) frame removes these attributes in step 4: fo:margin-left="0pt" fo:margin-right="0pt" fo:margin-top="0pt" fo:margin-bottom="0pt" style:run-through="foreground" style:wrap="none" style:horizontal-pos="from-left" style:horizontal-rel="paragraph-content" fo:padding="0pt" fo:border="none" style:shadow="none" The same element also has a change in attribute from style:vertical-pos="from-top" to style:vertical-pos="top". The <draw:frame> element for the "fr2" (graphic) frame includes these additional attributes in step 4: svg:x="0.11pt" svg:y="0.06pt" styles.xml: A new style is included: <style:style style:name="Frame_20_contents" style:display-name="Frame contents" style:family="paragraph" style:parent-style-name="Text_20_body" style:class="extra"/>
Please read this message in its entirety before responding. Your bug was confirmed at least 1 year ago and has not had any activity on it for over a year. Your bug is still set to NEW which means that it is open and confirmed. It would be nice to have the bug confirmed on a newer version than the version reported in the original report to know that the bug is still present -- sometimes a bug is inadvertently fixed over time and just never closed. If you have time please do the following: 1) Test to see if the bug is still present on a currently supported version of LibreOffice (preferably 4.2 or newer). 2) If it is present please leave a comment telling us what version of LibreOffice and your operating system. 3) If it is NOT present please set the bug to RESOLVED-WORKSFORME and leave a short comment telling us your version and Operating System Please DO NOT 1) Update the version field 2) Reply via email (please reply directly on the bug tracker) 3) Set the bug to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link: https://wiki.documentfoundation.org/QA/BugTriage There are also other ways to get involved including with marketing, UX, documentation, and of course developing - http://www.libreoffice.org/get-help/mailing-lists/. Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material
Tested under GNU/Linux using 4.2.8.2, 4.3.5.2, and 4.4.1.2. All versions exhibit the problem.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.5 or 5.1.2 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT - Update the version field - Reply via email (please reply directly on the bug tracker) - Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-04-16
Still a problem on v5.1.2.2 on Linux 64bits (openSUSE 13.2)
*** Bug 73385 has been marked as a duplicate of this bug. ***
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.4.1 or 5.3.6 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170929
Still a problem on Version 5.4.1.2
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Problem still present in 6.1.2.1
Dear RGB, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Problem still present in LibreOffice 6.3.2
Dear RGB, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Problem still present in LibreOffice 7.2.1.2.
*** Bug 152302 has been marked as a duplicate of this bug. ***
In my humble opinion, it makes sense to "transfer" that spacing from the image frame to the caption frame. If users change the spacing around an image before captioning it (per image, or using the Graphics style so it affects many images at once), they most likely want to keep that same spacing around the frame once the image is captioned, without needing to go through the whole process again. If it weren't transferred, they would end up with a caption that's closer to the surrounding text when I suspect most would want the caption to be closer to the picture. However, it is difficult to then change spacing around all graphics at once: editing the style to add extra spacing under all graphics would also affect the captioned graphics. My suggestion would be to: - keep the transfer of properties as is (from graphics properties to surrounding frame properties); however: - add a "Captioned graphic" style that is automatically applied to a captioned graphic, and - add a "Caption frame" style that is automatically applied to the surrounding frame. That way, it would be easy to handle these elements' styling separately, for example changing a property for all captioned graphics but not other graphics, or for all caption frames but not other frames. Of course, one would be able to set inheritance between those if they want them to be consistent. For example, making "Caption frame" inherit properties from "Graphics" so the spacing for the whole document can be set all at once. Thoughts? Maybe that feels even more heretic: automatically changing the style of the object. And I am focusing on spacing around an image, but it might not make sense for all properties (e.g. a custom frame border. Does one want to keep it surrounding only the image? Or the caption as well?)
Let me first address the caption issue, then the more general one which is more complicated. (In reply to Stéphane Guillou (stragu) from comment #18) > In my humble opinion, it makes sense to "transfer" that spacing from the > image frame to the caption frame. I would say that both options _partly_ make sense. That's because with a caption, you have two lengths of space: From the image to the caption and from the image+caption, or from the image, to the outside flow of content. With no caption, these coincide or alias each other - so different users will make different choices between the two. > My suggestion would be to: > > - keep the transfer of properties as is (from graphics properties to > surrounding frame properties); however: > - add a "Captioned graphic" style that is automatically applied to a > captioned graphic, and > - add a "Caption frame" style that is automatically applied to the > surrounding frame. I'm not sure I agree - because all sorts of frames can have captions. Do you want to triplicate all frame styles accordingly? What about styles the user has created? e.g. "Fancy Graphic" and "Subdued Graphic" or whatever? The larger issue is how transformations of frames are affected by styles of the original frames; and whether a family of related frames (e.g. outer frame, inner frame for captioned content, inner frame for caption) should have a style as a triplet, or a triplet of styles; and whether such styles need to be strongly linked; etc.
We discussed the topic in the design meeting. There are a lot of related issues. Inserted graphic receives a Graphic frame style (FS) with anchor To Paragraph but is anchored To Character (as defined in Tools > Options > Writer > Formatting Aids). The same is true on adding a caption with a Frame FS - it is defined as To Paragraph but is direct formatted as To Character. The actual problem here is the distance below the graphic. If set to some value it's kept if the caption is added - and while the distance between graphic and text was desired it's now to the caption, which in turn needs some distance to the text. Plus, the default is zero distance, which is not appealing. Solutions: * Frame styles should follow the definition. * We should not apply direct formatting. => needsDevAdvice * The default below a "Graphic" (and Frame) is better something like 0.2cm.
(In reply to Heiko Tietze from comment #20) > Solutions: or when adding a caption, do not add a frame with images (and charts) as suggested in bug 115318?
Don't think bug 115318 is going to fly. Commented there (essentially that floating objects need a frame).