Description: Image is moved over the text hence the text is not readable Steps to Reproduce: 1. Open the attached docx file. 2. Scroll over to the page 4 and check the image. 3. Image is moved above the text. Actual Results: Image is moved above. Expected Results: Image should be visible as it is in the original document. Reproducible: Always User Profile Reset: No Additional Info: Version: 25.2.0.3 (X86_64) / LibreOffice Community Build ID: e1cf4a87eb02d755bce1a01209907ea5ddc8f069 CPU threads: 22; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Created attachment 199484 [details] Sample.docx
Created attachment 199485 [details] Sample_Export_From_Libreoffice.pdf
Created attachment 199486 [details] Actual.png
Created attachment 199487 [details] Expected.png
Looks like a duplicate of tdf#162091
Confirm with Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e420583fee9f753e7de5a207637fda25e495ac7d CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded Position of imgae is coreect in Version: 5.2.0.0.alpha0+
This seems to have begun at the below commit in bibisect repository/OS bibisect-linux-64-6.0. Adding Cc: to Justin Luth ; Could you possibly take a look at this one? Thanks 18dbad8e429911299dbb8889038e182929398869 is the first bad commit commit 18dbad8e429911299dbb8889038e182929398869 Author: Jenkins Build User <tdf@pollux.tdf> Date: Mon Sep 4 19:17:04 2017 +0200 source e56f61c4637c09afbf125fa02f131b0c49e36351 41821: tdf#37153 ConsiderWrapOnObjPos: always affect anchoring cell | https://gerrit.libreoffice.org/c/core/+/41821
This is a compatibilityMode14 document, so it does NOT force layoutInCell. This particular OLE object is marked as layoutInCell. Yet it is also a WrapThrough object, so it is NOT bound by the cell margins - even though it is positioned according to the cell it is in (as opposed to the table paragraph). Opening it in Word 2010 gives a strange visual anchor point. It appears to be anchored a few rows below where it is defined. Oh - the cell is "bottom oriented" and the text is 2pt. So the visual anchor point should be the at the bottom of the cell the OLE object is in.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c7f049069c5022ee09d73841d9e32b685a3bd9d8 tdf#165478 revert ConsiderWrapOnObjPos: always affect anchoring cell It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/10b9d5200e382db5affaefc035ebe4d6b35a92fb tdf#37153 tdf#165478 sw: add mso-compat flag doNotVertAlignCellWithSp It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/d095923dbb1b27ddb98f675f003d8cd6ce76bf54 tdf#165478 revert ConsiderWrapOnObjPos: always affect anchoring cell It will be available in 25.2.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Interestingly, Otherbug2.docx (attachment 148829 [details] from bug 123104) seems to be a counter example. It is a compat14 that does not have "Don't vertically align table cells containing shapes", but still is showing as top aligned (until the anchored shape is deleted). With some testing, it seems that if the anchored shape's rectangle overlaps the cell, then the CR is pushed towards the top of the cell. (In other words, if I push horizontally out of the cell area, then the shape also drops as it now middle-aligns.) The point is that it CAN middle align, so my change is correct. My comment 10 patch is not a regression in this case, it has just exposed existing layout limitations.