Description: Image wrongly positioned after deleting header (fixed at save and reload) Steps to Reproduce: 1. Open the attached file 2. Delete the header -> Notice image being above highlighted text 3. Save 4. Reload Actual Results: Image at wrong position after deleting header Expected Results: proper Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha0+ (x64) Build ID: <buildversion> 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 164288 [details] Example file
Found in 6.0 Not in Versie: 5.3.5.2 Build ID: 50d9bf2b0a79cdb85a3814b592608037a682059d CPU-threads: 4; Besturingssysteem:Windows 6.2; UI-render: standaard; Layout Engine: new; Locale: nl-NL (nl_NL); Calc: CL
Reproduced in: Version: 7.1.0.0.alpha1+ Build ID: a373a7c1705b9abc5551388998131dacc4698642 CPU threads: 6; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: hu-HU (hu_HU.UTF-8); UI: en-US Calc: threaded
Bibisected using linux-64-6.0 to: URL: https://cgit.freedesktop.org/libreoffice/core/commit/?id=afc96d263959d10e457b54a574f0829d20e99df4 author: Justin Luth <justin_luth@sil.org> committer: Justin Luth <justin_luth@sil.org> summary: tdf#112352 ooxmlimport: ALWAYS treat 1st nextpage w/cols as cont Adding Cc: Justin Luth
(In reply to Attila Baraksó (NISZ) from comment #4) > Bibisected using linux-64-6.0 to: > summary: tdf#112352 ooxmlimport: ALWAYS treat 1st nextpage w/cols as cont This is a layout bug. Almost any editing change made will cause the image to jump back into the correct position - like adding or deleting a Carriage Return, etc. The commit will not be very helpful because it is an import fix, not a layout change. The only difference is where the columns are defined. Prior to 6.0 the columns were defined in the page style. After the commit, the columns are defined by the section.
Created attachment 167107 [details] 2345.odt: proof of non-regression - issue always seen in this ODT version. The layout problem goes back to at least LO 3.5. Almost certainly inherited from OOo.
Dear Telesto, 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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug