Description: Scrabbled text on file open caused by image Steps to Reproduce: 1. Open the attached file. Look at the second column 2. Open the attached file (from scratch) 3. Download the image 4. Place cursor before the marked text 5. Insert image -> Pick the download image Actual Results: Scrambled text Expected Results: Not so 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: default; VCL: win Locale: ru-RU (nl_NL); UI: en-US Calc: CL
Created attachment 163986 [details] Example file
Created attachment 163987 [details] File for do it your self
Created attachment 163988 [details] Image
Also found in 3.3.0
Telesto, unfortunately nothing has happened with this bug report for more than half year. So I'd like to ask, if it is still valid. Could you please try to reproduce it with the latest version of LibreOffice? => NEEDINFO
Still around Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 722ec600e85cca2e94e82e69f8d13773061172b9 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: nl-NL Calc: CL
I can confirm it, but only with your image from comment 3 Version: 7.1.1.2 (x64) / LibreOffice Community Build ID: fe0b08f4af1bacafe4c7ecc87ce55bb426164676 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL
(In reply to Dieter from comment #7) > I can confirm it, but only with your image from comment 3 > > Version: 7.1.1.2 (x64) / LibreOffice Community > Build ID: fe0b08f4af1bacafe4c7ecc87ce55bb426164676 > CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: > win > Locale: de-DE (de_DE); UI: en-GB > Calc: CL Correction: 2. Open the attached file (from scratch) 3. Download the image 4. Place cursor AFTER the marked text 5. Insert image -> Pick the download image
Lets focus the creating of such a document.. so comment 8.. because this is actually an regression Not in Versie: 6.3.0.4 (x86) Build ID: 057fc023c990d676a43019934386b85b21a9ee99 CPU-threads: 4; Besturingssysteem: Windows 6.3; UI-render: GL; VCL: win; Locale: nl-NL (nl_NL); UI-taal: nl-NL Calc: CL found in 6.4
This seems to have begun at the below commit. Adding Cc: to Miklos Vajna; Could you possibly take a look at this one? Thanks 135aa137d62e6fda825a468302eeeee4b24ff431 is the first bad commit commit 135aa137d62e6fda825a468302eeeee4b24ff431 Author: Jenkins Build User <tdf@pollux.tdf> Date: Wed Nov 20 00:08:03 2019 +0100 source a7528cd6f17ea5c5b29e7d607e54c62de0d9e7db https://git.libreoffice.org/core/+/a7528cd6f17ea5c5b29e7d607e54c62de0d9e7db sw: insert image: set anchor to at-char by default
I think the above just exposed a pre-existing bug, so this is rather an implementation error. If I revert the above commit on master but go to tools -> options -> writer -> formatting and set the default anchor type to at-char, the same happens. Inspecting the layout, this is clearly broken: the middle column has multiple text frames, and the first two overlaps. The first text frame top is at 1418 twips, it starts with a fly portion that has a height of 2851, so bottom of the portion is 4269 (and actual text only starts below that). In contrast to this, the 2nd text frame in that middle column already starts at 3074 twips. So yes, this is a bug, but it was there before as well. Adjusting keywords accordingly.
Attachment 163986 [details] now looks different at fileopen, since 7.6 and e40263b12055cbb95bb64ec6e81d3912152df900 (cherrypick of trunk's 61a78a523a6131ff98b5d846368e5626fe58d99c): no overlap, but quite a bit of text missing. Overlap is still reproducible when starting with do-it-yourself attachment 163987 [details]. With attachment 163986 [details], I can also reproduce a layout loop, one core stuck at 100%: place cursor before text right after image, press Enter. OOo 3.3 would crash shortly after doing that.