Created attachment 162388 [details] Sample slide (PPTX) The text box in this slide nicely fits into the slide on Office 365; with LibreOffice 7.1.0.0.alpha0+ Build ID: abe2a662cde10bb6d9308a85c60ab0b185183d41 CPU threads: 4; OS: Linux 5.6; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-06-21_15:25:29 it noticable shifts to the left, even beyond the border of the slide.
Created attachment 162389 [details] How it looks in LibreOffice - text box too far to the left
To clarify, the slide on the screenshot ends in the vertical green bar. I included the part of the overall window that includes the entire text, a fair bit of which no longer fits into the slide.
Created attachment 162413 [details] Comparison MSO 2010 and LibreOffice 7.1 master
Reproduced in Version: 7.1.0.0.alpha0+ Build ID: 42bf9bdf3d551eb59604f952204c49f7d7a1e913 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded and Version: 5.2.0.0.alpha0+ Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53 Threads 4; Ver: 4.19; Render: default; Locale: en-US (en_US.UTF-8)
Also reprpduced in Version: 4.3.0.0.alpha1+ Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e and Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
Repro OO. Inherited. PPT is fine. There's a trick here: after Text Box right-click Position and Size.. it appears OK, until next reload. Maybe LO is confused with text box small size so it centers wrong.
Created attachment 163146 [details] Another two slides exhibiting the same issue, I believe I believe I ran into this again in a completely different context, and came to the same conclusion as Timur: (In reply to Timur from comment #6) > Maybe LO is confused with text box small size so it centers wrong. Version: 7.1.0.0.alpha0+ Build ID: 9006cbf6a13317a386194d6857f22391464c2aa0 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-07-16_00:51:18
Created attachment 163147 [details] Another two slides exhibiting the same issue, I believe (version 2)
Created attachment 163148 [details] Comparision 365 and LO 7.1 master of the first page of the second document
The error is in https://opengrok.libreoffice.org/xref/core/oox/source/drawingml/textbodypropertiescontext.cxx?r=ef08f18e#73 Because MS Office has "not centered" as default and LibreOffice has "centered" in its default style, the value "not centered" needs to be set explicitly. So instead of mrTextBodyProp.mbAnchorCtr = rAttribs.getBool( XML_anchorCtr, false ); if( mrTextBodyProp.mbAnchorCtr ) mrTextBodyProp.maPropertyMap.setProperty( PROP_TextHorizontalAdjust, TextHorizontalAdjust_CENTER ); it needs to be mrTextBodyProp.mbAnchorCtr = rAttribs.getBool( XML_anchorCtr, false ); if( mrTextBodyProp.mbAnchorCtr ) mrTextBodyProp.maPropertyMap.setProperty( PROP_TextHorizontalAdjust, TextHorizontalAdjust_CENTER ); else mrTextBodyProp.maPropertyMap.setProperty( PROP_TextHorizontalAdjust, TextHorizontalAdjust_LEFT ); I have not tested, whether other places have to be adapted in addition. At least the import works with this change.
Is it possible this has been addressed in the meantime? I appear not to be able to reproduce this for the original document nor "Another two slides" with current -dev builds of LO 7.1 and LO 7.0? Digging into this a bit, it appears bug #137023 (which is newer than mine ;-) is a duplicate by Xisco that got fixed by Miklos? - Xisco?
(In reply to Xisco Faulí from comment #4) > Reproduced in ... > Version: 5.2.0.0.alpha0+ > Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53 > Threads 4; Ver: 4.19; Render: default; This was a bit unfortunate choice of version, indeed the bug is there in 5.2.0.4, but it's gone in 5.3.0.3, thus this wasn't an old issue, but a recent regression. (In reply to Gerald Pfeifer from comment #11) > Digging into this a bit, it appears bug #137023 (which is newer than > mine ;-) is a duplicate by Xisco that got fixed by Miklos? It's actually a duplicate of bug 129685, confirmed using the bibisect-linux-64-7.1 bibisect repo (bug 137023 is a regression from that other bugfix). *** This bug has been marked as a duplicate of bug 129685 ***
(In reply to Aron Budea from comment #12) > (In reply to Xisco Faulí from comment #4) > > Reproduced in > ... > > Version: 5.2.0.0.alpha0+ > > Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53 > > Threads 4; Ver: 4.19; Render: default; > This was a bit unfortunate choice of version, indeed the bug is there in > 5.2.0.4, but it's gone in 5.3.0.3, thus this wasn't an old issue, but a > recent regression. Ouch, nice catch!! Happy to see the issue is fixed!!