Apache OpenOffice (AOO) Bugzilla – Issue 20260
Trailing spaces generate blank line, differently from Powerpoint.
Last modified: 2017-05-20 11:11:37 UTC
Impress's handling of trailing spaces in a text box is different from Powerpoint. When you add spaces at the end of a line in a textbox, Powerpoint let the cursor move outside the text box and does not generate new line until you enter a non-space character. Whereas Impress generates new line immediately after the cursor reaches the right end of the textbox. Due to this difference Impress pushes bottom lines of some text boxes too down for some PPT files created by Powerpoint.
Created attachment 9743 [details] Screen of a test file in Impress
Created attachment 9744 [details] Screen of a test file in Powerpoint
Created attachment 9745 [details] The test PPT file
Reassigned to Christian.
The problem are the spaces outside the textbox. Place your cursor in the line 'however, in Powerpoint they ...' and press the 'End' key. You see that the cursor is outside the textbox. Delete the spaces outside the textbox and save the file again. After loading the 'changed' file in Impress there is no gap.
Hi Matthias As discussed here is the summary: - PPT-Import: Delete the Trailing spaces and insert a soft return - PPT-Export: Delete the spaces in the 'first' line and insert a soft return, keep the leading spaces in the 'second' line - Load old and current Impress files: Keep all spaces, new lines and end of lines.
-
MMP>KA: we have a proposed solution that seems to be too much effort for Q (according to Sven Jacobi). Can you please take a look and decide if this fits into our Q priority "interoperability", anyway?
I'd like to leave this on 'OOo Later' due to the heavy workload we have in this area, but this task has definitely the highest priority when fixing bugs taken out of the Later pool for OOo 2.0. => SJ, please take care of this task appropriately
accepted
Please have a look to the internal bug 114649. It's duplicate to this issue.
sj->tl: This is an outliner/editengine problem, so please take over.
Oh, now OOo 2.1 can fix this problem? Many other problems are ref to this one.
Created attachment 39828 [details] this patch is better, please test
I do not accept this patch as it is now. If we change only the default behaviour of the edit engine, we change the layout of existing OpenOffice documents. We will not fix an issue by introducing a new one. As sven explained to me we also can't fix this issue by removing or introducing whitespaces during ppt import and export. So the only way to solve this issue is to introduce some kind of a compatibility setting at a shape that defines if the new formating is used or not. This must be set at the ppt import and must also be stored persistent in the OOo xml format. Therefore thesetasks are left to solve this issue - add code to ppt import to set this compatibility flag on each importet shape - add code to xmloff to import and export this compatibility flag - add code to edit engine to only use new formating if compatibility flag is set - introduce compatibility flag to oasis file format
if( pNode->GetChar( nBreakInLine ) == ' ' || pNode->GetChar( nBreakInLine + nLineStart ) == cBlankCJKChar ) This looks wrong, why nBreakInLine and then nBreakInLine + nLineStart?
Yes, it is wrong, and should be: if( pNode->GetChar( nBreakInLine + nLineStart ) == ' ' || pNode->GetChar( nBreakInLine + nLineStart ) == cBlankCJKChar ) I think this issue is not good in fact, and I like OOo behaviour. But somebody think MS PPT is standard, I find I understand some code of OOo behaviour. This issue is so long, I want to give you some patch for your test only and I think maybe learn more knowledge about OOo.
retargeted
Reset assigne to the default "issues@openoffice.apache.org".