Created attachment 164805 [details] pptx Image of the formula in the uploaded slide is displaced in Impress and covering the text while it's correct in powerpoint. For the comparison, I'm uploading pics of how it appears in powerpoint which can be compared to document uploaded opened by Impress. Or one can open the document in powerpoint oneself. Version: 7.0.0.3 Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-IN (en_IN); UI: en-US Calc: threaded
Created attachment 164806 [details] as it originally appears in powerpoint
Created attachment 164807 [details] as it originally appears in LO
discussion at https://ask.libreoffice.org/en/question/259150/powerpoint-compatibility-image-is-displaced-in-impress-and-covering-the-text/
Quoting from AskLibreOffice: "Not the image is displaced, but the outline-textbox is filled differently. The outline-textbox has the property "Shrink on overflow" enabled. It seems LibreOffice and PowerPoint interpret it differently. And in PowerPoint there is an empty line after the last text in the outline-textbox, which is not there in LibreOffice. At least this missing line looks like an error in LibreOffice." Both PowerPoint and Impress ignore blank lines when auto-fitting. Auto-adjusting text size is so subjective that I wouldn't call this a bug. If the user doesn't want the textbox to be covered by the image, then the textbox should just be shrunk in size.
Confirming with: Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 86c8c775bbefe333d684e12c99855a3c1de68051 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: en-US (hu_HU); UI: en-US Calc: CL
Repro Version: 7.1.0.0.alpha1+ (x64) Build ID: 738bcf5e9a8c443d60c29c3a8068e8c16c72638a CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: en-US Calc: CL Version: 7.2.8.0.0+ (x64) / LibreOffice Community Build ID: ffa09959edd087794b1f2fe6b9b6faac484ef74b CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: en-US Calc: CL Version: 7.3.0.0.alpha1+ (x64) / LibreOffice Community Build ID: 229123ccc6f90ebf66b3e659bebbd53f8a9bdd3a CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: en-US Calc: CL Version: 7.4.8.0.0+ (x64) / LibreOffice Community Build ID: f8ba7c6f77497e2dc7bfef8378511e2074ce01f9 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: en-US Calc: CL Version: 7.6.0.0.beta1+ (X86_64) / LibreOffice Community Build ID: 1b5cee822e0bc15ddbdfc86926678ca35ab3e082 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: en-US Calc: CL threaded The bug is bigger in this version of LO because the part of the text which is hidden is bigger: Version: 7.5.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 1c629ca0048670db4bed5e7d8d76bcf8e81f2158 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: en-US Calc: CL threaded
Good news! I can reproduce this with Version: 7.6.7.0.0+ (X86_64) / LibreOffice Community Build ID: 88f6a250076eb2a825084c84193b84f3b94ce112 CPU threads: 12; OS: Linux 6.11; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Version: 24.2.8.0.0+ (X86_64) / LibreOffice Community Build ID: 0e74b05b607d931d63762b7d8f69f59b457c1e17 CPU threads: 12; OS: Linux 6.11; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US It is no longer present with Version: 24.8.4.0.0+ (X86_64) / LibreOffice Community Build ID: a78d19714c232b0c18ef48271e7a8372ebe8dbe8 CPU threads: 12; OS: Linux 6.11; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 43cd683230bc05d294b1bd64f1e7932feccdd3fb CPU threads: 12; OS: Linux 6.11; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US So it appears this has been addressed, even if we don't know the specific commit.