Bug 140022 - FILEOPEN PPTX: one column becomes two within one text frame (two occurrences)
Summary: FILEOPEN PPTX: one column becomes two within one text frame (two occurrences)
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
6.2 all versions
Hardware: All All
: medium normal
Assignee: Miklos Vajna
URL:
Whiteboard: target:7.3.0 target:7.2.3
Keywords: bibisected, bisected, implementationError
Depends on:
Blocks: Textbox-column
  Show dependency treegraph
 
Reported: 2021-01-30 15:00 UTC by Gerald Pfeifer
Modified: 2021-10-23 06:10 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Sample slide (in PPTX format) (602.30 KB, application/vnd.openxmlformats-officedocument.presentationml.presentation)
2021-01-30 15:00 UTC, Gerald Pfeifer
Details
Screenshot comparing Office 365 (left) and LO 7.2 (right) (240.05 KB, image/png)
2021-01-30 15:01 UTC, Gerald Pfeifer
Details
The example file in PP and Impress nightly (85.94 KB, image/png)
2021-06-09 12:13 UTC, NISZ LibreOffice Team
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gerald Pfeifer 2021-01-30 15:00:13 UTC
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
Comment 1 Gerald Pfeifer 2021-01-30 15:01:26 UTC
Created attachment 169302 [details]
Screenshot comparing Office 365 (left) and LO 7.2 (right)
Comment 2 Xisco Faulí 2021-02-15 18:27:08 UTC
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
Comment 3 Xisco Faulí 2021-02-15 18:34:25 UTC
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
Comment 4 Miklos Vajna 2021-02-16 11:05:53 UTC
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.
Comment 5 NISZ LibreOffice Team 2021-06-09 12:13:36 UTC
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.
Comment 6 NISZ LibreOffice Team 2021-06-09 12:14:37 UTC
@Mike I thought you might be interested in this one.
Comment 7 Mike Kaganski 2021-07-30 08:08:17 UTC
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.
Comment 8 Miklos Vajna 2021-10-22 08:16:20 UTC
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.
Comment 9 Commit Notification 2021-10-22 09:37:33 UTC
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.
Comment 10 Miklos Vajna 2021-10-22 11:36:13 UTC
I think this is now fixed on master + libreoffice-7-2.