<html>
<head>
<base href="https://bugs.documentfoundation.org/">
</head>
<body><span class="vcard"><a class="email" href="mailto:mikekaganski@hotmail.com" title="Mike Kaganski <mikekaganski@hotmail.com>"> <span class="fn">Mike Kaganski</span></a>
</span> changed
<a class="bz_bug_link
bz_status_NEW "
title="NEW - FILEOPEN PPTX: one column becomes two within one text frame (two occurrences)"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=140022">bug 140022</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Assignee</td>
<td>libreoffice-bugs@lists.freedesktop.org
</td>
<td>mikekaganski@hotmail.com
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - FILEOPEN PPTX: one column becomes two within one text frame (two occurrences)"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=140022#c7">Comment # 7</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - FILEOPEN PPTX: one column becomes two within one text frame (two occurrences)"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=140022">bug 140022</a>
from <span class="vcard"><a class="email" href="mailto:mikekaganski@hotmail.com" title="Mike Kaganski <mikekaganski@hotmail.com>"> <span class="fn">Mike Kaganski</span></a>
</span></b>
<pre>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 <a href="https://gerrit.libreoffice.org/c/core/+/119698">https://gerrit.libreoffice.org/c/core/+/119698</a>.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>