Description: Image padding is lost when a document is exported to a DOCX file. Steps to Reproduce: 1. Insert an image 2. Set some padding on the image 3. Save the document as a DOCX file 4. Close and re-open the file Actual Results: The image no longer has any padding. Expected Results: The padding should be maintained. Reproducible: Always User Profile Reset: No Additional Info: Version: 24.8.0.3 (x86) / LibreOffice Community Build ID: 0bdf1299c94fe897b119f97f3c613e9dca6be583 CPU threads: 20; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Vulkan; VCL: win Locale: en-GB (en_GB); UI: en-US Calc: threaded
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
Created attachment 196174 [details] Image with padding
The image is anchored as character. For such anchored images the attributes distR and distL are disabled in OOXML. So being conform to OOXML, Word has to ignore these attribute. 20.4.2.3 anchor (Anchor for Floating DrawingML Object), part 1 OOXML: <quote> If this object is an inline object (i.e. has a parent element of inline), then this value shall not have any effect when displaying the object in line with text, but can be maintained and used if the object is subsequently changed to floating. </quote> Thus these attributes cannot be used. And as the image is anchored inline, a wrap polygon can be used neither. So the target file format has no means to describe such distance in case of object anchored as characters. As consequence, all parts to add such distance are disabled in Word if the image is anchored as character. You could drag the crop handles to get a distance to the text. But that produces negative crop values and negative values are not allowed in ODF. So I see no way to describe such distance, so that a corresponding OOXML attribute exists and at the same time it is valid ODF. I'm not sure about a bug solution, could be WONTFIX, NOTABUG, NOTOURBUG. When you need "anchored as image", then you need a workaround. In that case you should discuss it on Ask. If you do not care about valid ODF, you can use negative crop instead of padding.
Thank you. Personally, I'm happy with the negative crop solution, now that I know about it. I do think it would be better, though, if LibreOffice did this for you on export to DOCX if you have set padding on an inline image. Users expect an exported DOCX to be as near identical as possible to the original. I don't care about it being valid ODF as long as it works and is guaranteed (well, likely) to continue to work. Out of interest, where does it say that it's not valid ODF, and why is that?
I was wrong. Negative crop is possible in ODF. I have mixed it up with negative padding, that is not possible (bug 96066). So it is fine, when you go with crop. I have no particular opinion on whether LibreOffice should perform an automatic conversion. All such things make the code complicated and error-prone. I would be more in favor of an overview in the Wiki, about things that should be avoided and what you need to know, if exchange with OOXML formats is absolutely necessary. Our QA-team will decide, whether your report is accepted. If yes, then likely as enhancement request.
Thanks again.
Clarifying summary, but it seems like a risky proposal, so I won't set to NEW. I don't think QA team should decide such.
I asked in the dev chat and Mike K. said "we do all kinds of approximations all the time. In case of floating tables, it was especially grand, before Miklos implemented the proper support". So let's accept the request.