Description: FILEOPEN RTF: Image jumps out of table when pressing arrow up (no free movement) Steps to Reproduce: 1. Open the attached file 2. Save As RTF 3. File reload 4. Select one of both images and press arrow up -> If it jump out of table it's wrong Actual Results: Jumping out of table Expected Results: Shouldn't. Doesn't do this in ODT nor in DOCX Reproducible: Always User Profile Reset: No Additional Info: Found in 7.1 and in 5.4 no image in 5.3 5.2 5.1 fine in Versie: 5.0.0.1 Build ID: 9a0b23dd0ab9652e0965484934309f2d49a7758e Locale: nl-NL (nl_NL)
Created attachment 164076 [details] Example file
Created attachment 164077 [details] ODT based on RTF based (with the same flaw) for 5.1-5.3
(In reply to Telesto from comment #2) > Created attachment 164077 [details] > ODT based on RTF based (with the same flaw) for 5.1-5.3 Of course.. If you save the RTF to ODT you get same effect until 3.3.0
@Justin They anchoring stuff is still beyond me. The STR Comment 0 worked perfectly in 5.0 but is broken somewhere between 5.1-5.3.. So you can export they RTF with 7.1 and import the file in 5.0 with proper behavior However if you export the RTF to ODT again with say 7.1, you get a ODT with they love broken behavior, which appears already in 3.3.0. Even assuming people don't use RTF save to often, there is also RTF paste (which produces the same lovely result) How complicated/ twisted can it be made. So you have different kinds of anchoring behavior with the same anchor depending on how the image got 'inserted' into the document (RTF paste/regular insertion).
This might partly caused by page wrap being converted to non (or imported as such). But even re-enabling page wrap makes the behaviour being off, IMHO
I don't get it. (Ubuntu 20.04, LO 7.1 or LO 6.4.6) If I open comment 1's e343d4.odt, select an image, and press up-arrow, then the picture jumps out of the table. I don't need to save as RTF or anything. Now DOC/DOCX is different, because it exports the image with "Keep inside text boundaries" (aka Layout in table cell). In that case it ought not to move outside of the cell. I assume that in general it is best to export an image inside of a table with "Layout in table cell" for MS formats to emulate LO. Indeed, as soon as you drag an image into a table in Word 2003 (or any change at all for that matter), it automatically enables that option. And Word 2013 even ignores a "Layout in table cell" = false. So it seems to me this is a WONTFIX (unless someone wants to enable Keep inside text boundaries on RTF import as well). P.S. In Word 2003, even with that flag enabled, the up arrow still moves the picture out of the table - so even this reportedly buggy behaviour matches Word.
(In reply to Justin L from comment #6) > I don't get it. (Ubuntu 20.04, LO 7.1 or LO 6.4.6) > > If I open comment 1's e343d4.odt, select an image, and press up-arrow, then > the picture jumps out of the table. I don't need to save as RTF or anything. I agree. The only difference is, that wrap of image in odt-file is "Optimal", while it is "None" in RTF. So if you change wrap in rtf-file to optimal you get the same result as with odt-file. So if you like we can treat change of image wrap as a bug, but I suggest to open a new bug report for that. Telesto, Justin, what do you think? => NEEDINFO Tested with Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: b733ccad171e6def8fbdb93f31875dfdea47bdc6 CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL
Dear Telesto, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear Telesto, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp