Bug 79082 - FILESAVE: Tab positions not being retained in PPT and being lost in PPTX
Summary: FILESAVE: Tab positions not being retained in PPT and being lost in PPTX
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords: filter:ppt, filter:pptx, patch
Depends on:
Blocks: PPTX PPT
  Show dependency treegraph
 
Reported: 2014-05-22 18:23 UTC by Alexander
Modified: 2018-10-22 02:49 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
test case (127.80 KB, application/x-zip-compressed)
2014-05-22 18:23 UTC, Alexander
Details
Zip file with example files Tabs.odp, Tabs.ppt, Tabs2.ppt, Tabs.pptx (60.62 KB, application/zip)
2014-09-16 16:01 UTC, Piet van Oostrum
Details
Proposed patch (2.15 KB, patch)
2014-10-31 00:27 UTC, Piet van Oostrum
Details
Unwanted tabs (61.05 KB, image/png)
2015-11-21 09:19 UTC, Alexander
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander 2014-05-22 18:23:10 UTC
Created attachment 99595 [details]
test case

Problem description: 
On it's own adds tab positions to paragraph when saving in Office XP format

Steps to reproduce:
1. Create presentation with a paragraph with no tab stops
2. Save it to format Microsoft PowerPoint 97/2000/XP/2003 (.ppt)
3. Close and open the presentation

Current behavior:
Tab stops appeared in the paragraphs where were absent 

Expected behavior:
Tab stops shouldn't have appeared

It changes the text appearance after the document is closed and opened again.

Thanks

Operating System: Windows 8
Version: 4.2.4.2 release
Comment 1 Piet van Oostrum 2014-09-16 15:54:15 UTC
I have some additional info because I got (almost) the same problem. I use LibreOffice 4.3.1.2 on Mac OS X 10.6.8.
I got the same problem when I had defined tab stops for a paragraph (see the attached Tabs.odp and the paragraph with the sample text. I set tanb stops at 0 4 and 10cm. My default tab stops were set at 1.25cm. The tab stops in the powerpoint file (Tabs.ppt) got set at multiples of 1.25cm, but with an offset (start at 0.3cm). 

Then when I changed the default tab stops to 2.0 cm and saved the file again as PPT (Tabs2.ppt) the stops changed to multiples of 2cm (again with an offset).

And, by the way, when saving to PPTX, the tab stops just disappear (Tabs.pptx).

All the example files in Tabs.zip.
Comment 2 Piet van Oostrum 2014-09-16 16:01:47 UTC
Created attachment 106377 [details]
Zip file with example files Tabs.odp, Tabs.ppt, Tabs2.ppt, Tabs.pptx
Comment 3 Yousuf Philips (jay) (retired) 2014-09-30 03:28:23 UTC
Hello Alexander,

Thank you for submitting the bug. This isnt a bug because impress' default tabs spacing is 2 inches and in order to preserve this tab size in a .ppt file, it has to put them into the file, so that if you opened in up in powerpoint, the file would appear in the same way. Powerpoint on the other hand has a default tab spacing of 1 inch.

Hello Piet,

Thank you for contributing to the bug. Yes i can confirm that tabs are not being saved correctly in ppt and being lost when saving to pptx.

Version: 4.4.0.0.alpha0+
Build ID: df73f4115cfe4d07e4159adf087571687eb173ec
TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2014-09-25_23:36:54
Comment 4 Piet van Oostrum 2014-10-31 00:19:10 UTC
I found the problem. I loaded the Tabs.ppt file in Powerpoint (the real one on Windows) and the tabs were there. So the problem appears to be on importing the PPT file in Impress. 

In libreoffice-4.3.2.2/filter/source/msfilter/svdfppt.cxx, line 6160 there is a line

    if ( mbTab )    // makes it sense to apply tabsettings

which makes setting the tab stops in a paragraph conditional upon there being real tabs in the paragraph, supposedly as a kind of optimization. On a slide master the tabs are retained, however.

This is bad for 3 reasons:
1. It is not a good idea to throw away information that a user has put deliberately in a file.

2. If the user intends to edit the imported PPT file, and add some tabs then (s)he has to recreate the tabs.

3. [This is the most serious one]. In Powerpoint 97-2003 a text frame can only have one sets of tab stops for all paragraphs. When a PPT file is saved in e.g. Powerpoint 2007 or 2010, the tab stops of the first paragraph of the text frame is used and the tab stops of the subsequent paragraphs in the same text frame disappear. The Impress PPT export code does the same as it has no choice. Now suppose the imported PPT file has the first paragraph without tabs in it but the next one does have them. Then when you make some change to the file and save it again as PPT, the tabs in the text frame will be replaced by the default tab stops because the tab stops of the first paragraph had been deleted on the import.

So that test should be eliminated. As mbTab is only used for this purpose also the code to set it can be eliminated.

There was also a second issue, that the default tabs that were in the imported presentation had an offset of 0.3 cm. This is caused by the fact that the default tab stops that the paragraph gets come from the slide master. The paragraph in the slide master has an indent of 0.3 cm (in this presentation), because it is bulleted.

Now in PPT tab stops are relative to the left margin of the text frame, but in Impress they are relative to the text indent. So on import export this has to be compensated, which is just what happened.
Comment 5 Piet van Oostrum 2014-10-31 00:27:54 UTC
Created attachment 108711 [details]
Proposed patch

I have tested this patch and it solves the problem for the PPT import
Comment 6 Markus Mohrhard 2014-11-02 16:20:04 UTC
Please send the patch either to the developer mailing list or to gerrit (https://wiki.documentfoundation.org/Development/gerrit) as we are not monitoring bugzilla for patches. Additionally patches for import/export filters are easier to review if they include a test case.
Comment 7 A (Andy) 2015-11-20 22:34:46 UTC
For me not reproducible with LO 5.0.3.2, Win 8.1.

Does this issue still persist?
Comment 8 Alexander 2015-11-21 09:19:51 UTC
Created attachment 120696 [details]
Unwanted tabs
Comment 9 Alexander 2015-11-21 09:21:30 UTC
(In reply to A (Andy) from comment #7)

Actually it is (LO 5.0.3.2, Win 8.0). Added another attachment.
Comment 10 Yousuf Philips (jay) (retired) 2015-11-26 14:45:48 UTC
I pushed Piet's patch in comment 5 into gerrit, though it is of importing of tabs, which isnt what is being addressed by this bug.

https://gerrit.libreoffice.org/20207

@Piet: Can you please provide a license notice for your patch. Visit https://wiki.documentfoundation.org/Development/Developers to find out how to send it in.
Comment 11 Piet van Oostrum 2015-11-26 17:13:01 UTC
I already submitted my license statement some time ago.
Comment 12 Piet van Oostrum 2015-11-26 17:13:43 UTC
This bug report actually covers 3 different bugs. It would be better to split them up into separate bug reports.
Comment 13 Yousuf Philips (jay) (retired) 2015-11-26 18:25:27 UTC
The initial bug(In reply to Piet van Oostrum from comment #11)
> I already submitted my license statement some time ago.

Thanks.

(In reply to Piet van Oostrum from comment #12)
> This bug report actually covers 3 different bugs. It would be better to
> split them up into separate bug reports.

The bug description is about the tab saving issue, so other issues should be opened in separate bugs.
Comment 14 Robinson Tryon (qubit) 2015-12-07 16:36:27 UTC Comment hidden (obsolete)
Comment 15 QA Administrators 2017-01-03 19:39:24 UTC Comment hidden (obsolete)
Comment 16 Alexander 2017-01-04 07:53:26 UTC
Have installed LO 5.2.4 in Win8 but couldn't start it. The start up screen was hanging for more than 5 min before I killed it.
Comment 17 Alexander 2017-01-04 10:00:00 UTC
Succeeded 32bit version:
Version: 5.2.4.2
Build ID: 3d5603e1122f0f102b62521720ab13a38a4e0eb0
CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; 
Locale: ru-RU (ru_RU); Calc: group

The bug is present, the behavior is the same, nothing changed.
Comment 18 QA Administrators 2018-10-22 02:49:06 UTC
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug