Created attachment 169301 [details] Sample slide (in PPTX format) How to reproduce: 1. Open sample document. 2. Observe how both text blocks wrap into two columns, running over each other. 3. Compare with screenshot comparing LO and PPTX Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: 6c8a6b6aa2f962bd2fadbdf27405bfcd7d167fec CPU threads: 8; OS: Linux 5.10; 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: 2021-01-25_04:01:09 Already in Version: 6.4.8.0.0+ Build ID: 99b065ec31d032fc08ab14f66430dac4fef904a5 CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:libreoffice-6-4, Time: 2020-10-08_08:57:08
Created attachment 169302 [details] Screenshot comparing Office 365 (left) and LO 7.2 (right)
Reproduced in Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: cbcec4425e04e3614a2025b49fdc221216ac51d3 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=aef569ed83a3ccc02639e5b2a1c7cc131ba262fc author Miklos Vajna <vmiklos@collabora.co.uk> 2018-09-21 11:50:57 +0200 committer Miklos Vajna <vmiklos@collabora.co.uk> 2018-09-21 13:30:20 +0200 commit aef569ed83a3ccc02639e5b2a1c7cc131ba262fc (patch) tree 90bf85cdf5359ec5e300000d396cd13d33e924fb parent 356db87a6b622722d0d04ee3e17730a96865770a (diff) tdf#120028 PPTX import: map shapes with multiple columns to table shapes Bisected with: bibisect-linux64-6.2 Adding Cc: to Miklos Vajna
I believe this is a missing feature. PPTX (but not PPT) has the concept of multi-column shape text, while Impress shapes can't have multiple columns. The above commit does a best-effort conversion of shape text with multiple columns into a table shape: if you have N columns then you get a table with a single row and N columns. This conversion has the downside that we need to distribute content at import time, so e.g. in the second shape of the bugdoc you have 5 paragraphs: we put 3 paragraphs to the A1 cell and 2 paragraphs to the B1 cell. It's not like I can sit down and "fix" this: to have better presentation of this in Impress, we would have to add a feature to have multiple columns in an editeng text; but that was missing even before the above commit. Adjusting keywords accordingly.
Created attachment 172732 [details] The example file in PP and Impress nightly Looks a bit better in todays nightly after bug 118458 was fixed, but not perfect yet: Version: 7.2.0.0.alpha1+ (x64) / LibreOffice Community Build ID: 31ed81ea71a20ec119805f66a42f99b3f80d2dc5 CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: default; VCL: win Locale: el-GR (hu_HU); UI: en-US Calc: CL Two columns are now present, but the text is equally balanced between them in Impress instead of filling up the first column completely like in PP.
@Mike I thought you might be interested in this one.
I would not call this "implementation error" or "regression" :) - rather it's a RFE to implement a special processing in some cases. It turns out that MS Office has an interesting feature when using columns in an object having "fit height to text" setting. When one types text, the text goes into first column first, then second, etc.; then it re-flows to have two lines per column; three lines ... as needed to fit all text. The object size grows accordingly. That's all OK and corresponds to what LO does. But when one then decides to remove some text from the object, MS Office would *not* re-balance the rest of the text over the columns: it will keep the old object height, and remove last columns, keeping first column's height, until there's not enough text in that first column - and only at that point it starts to shrink the object size. This behavior makes the multi-column text unbalanced! Of course we did not implement such an unexpected behavior that might be considered surprising - but OTOH, it does not make anything impossible, and it obviously enables some possibilities - so we need to introduce that specialty. It would help interoperability, and at the same time, enable same opportunities. What happens reading the attachment is that there is a large height of the objects in the file; LibreOffice reads the height info, and applies it to the objects; then, according to "fit height to text", it calculates the text height to update the object height - but the text is balanced to evenly fill the available space, and so the resulting height is decreased, and the end result is as it is. What is needed is that we do not shrink the text height until there's enough lines at least in one column - both at import stage, and at editing process for consistency. Considering that implementing it does not break any existing files generated by LO, we need not a compatibility setting or any options. WIP is at https://gerrit.libreoffice.org/c/core/+/119698.
https://cgit.freedesktop.org/libreoffice/core/commit/?id=ea5d4bab6c54432bf590f8650d9f5ea930a0daaa is meant to fix this on master, just I forgot to mention the bug number in the commit message.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/7e74c6cf8d0a56cc061f48e1c6f397d393165220 tdf#140022 sd: fix inteaction between multi-col shape text and automatic height It will be available in 7.2.3. 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.
I think this is now fixed on master + libreoffice-7-2.