Description: Image anchored as 'as character' moves to different spot on DOCX/DOC/RTF export Steps to Reproduce: 1. Open the attached file 2. Save as DOCX/DOC/RTF 3. File reload Actual Results: Image goes to top next to text Expected Results: MSO doesn't allow moving the image, so export seems OK. Question is should movement be allowed within ODT Reproducible: Always User Profile Reset: No Additional Info: Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: ddc57169ac8d1de00403dbb09fef5221beaa0f3d CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Created attachment 176572 [details] Example file
Tested with Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 2934472ab888ebfe64a153984af2902fac63a7a0 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL Image is also on top net to the text when opening in Word 2016. I can see, that image is anchored "as character" but I can't see the anchor. So I can't really see, what's happening. Can you check this?
The position in ODT is "Vertical BOTTOM to Base line". Likely MS Formats don't have such a positioning thing. This kind of information should have been provided in the original description, and identified before the bug report was created. Please provide proof that MS formats can specify a similar anchor setting. Assuming DOCX-Limitations.
(In reply to Justin L from comment #3) > The position in ODT is "Vertical BOTTOM to Base line". Likely MS Formats > don't have such a positioning thing. > > This kind of information should have been provided in the original > description, and identified before the bug report was created. Sorry.. but I admit this kind of analysis not being my strong point. > Please provide proof that MS formats can specify a similar anchor setting. > Assuming DOCX-Limitations. Well this beyond me capability's.. So lets assume you're right.. This still leaves to possibility's A) transposition/Conversion of anchor from 'As Character' to "To Character" anchor on save which matches the position on canvas. There was a short while, where DOCX shapes got imported as 'as character'. But quickly changed to 'To Character' for usability reasons B) Avoiding that "Vertical BOTTOM to Base line" being used (probably impossible). LibreOffice has a tendency to defining the position using "Vertical BOTTOM to Base line" if you drag the image. So it's something which can easily happen. 1. Open Writer 2. Insert a shape -> rectangle at cursor position of the empty document 3. Change anchor to 'as character' 4. Open the position dialog: result Position: Center -> Baseline 5. Drag the shape down with the mouse: result Position: Vertical Bottom to Base line 6. Save to DOCX (x.docx) 7. File reload -> Shape will be on top of the page 8. Open the file x.docx with Word 2003 -> Image properly positioned (odd..) 9. Save the file to y.docx 10. Open y.docx file with Writer -> notice anchor change to 'to character' and shape on the proper position 9. Open x.docx with Word Online -> Image on top of the page (as in 7)
(In reply to Justin L from comment #3) > > Please provide proof that MS formats can specify a similar anchor setting. > Assuming DOCX-Limitations. The UI of Word has no setting for the vertical position of the shape in case it is anchored 'inline'. But Word treats such image as character and you can use the character properties of subscript and superscript to set the image to the desired vertical position. So a solution could be to convert vertical position to character subscript/superscript on export and the other way round on import.
(In reply to Regina Henschel from comment #5) > The UI of Word has no setting for the vertical position of the shape in case > it is anchored 'inline'. But Word treats such image as character and you can > use the character properties of subscript and superscript to set the image > to the desired vertical position. So a solution could be to convert vertical > position to character subscript/superscript on export and the other way > round on import. I'm sorry, that I don't understand everything, so let me just simply ask: Would you treat current behaviour as a bug or is an enhancement needed, or ...?