python-pptx output cannot be opened in Keynote (resubmit of #66)

[tvanyo]

I saw issue 66 and thought I would contribute some debugging files.

I created a pptx from python-pptx and confirmed it wouldn't open in Keynote. Saved to another name in PowerPoint and this new file could be opened in Keynote. I installed opc-diag and generated the output.

github n00b, so now I need to figure out how to upload the files.

[dskrad]

I noticed that the mime-type of pptx files generated by the module is "application/octet-stream" while files made by MS powerpoint are mime-type "application/vnd.ms-powerpoint". Perhaps this bug can be fixed.

[scanny]

Where are you finding the MIME type? As far as I know the file does not contain a MIME-type of its own. In general, this sort of thing is applied externally as far as I've ever known.

[dskrad]

file -i test.pptx

I ran into trouble when I was trying to serve the file over the web via apache. The webserver was not sending the file for some reason or the browser was rejecting it. So I checked my /etc/mime.types and all the docx, pptx, etc formats were declared. So then I ran the above command and discovered that the mime type was octet-stream which is not the same as the mime type that MS powerpoint outputs. I thought this was tangentially related to this issue of Keynote not being able to open it until it was opened and saved by Powerpoint with a new file name.

[dskrad]

Oh... And the file with correct mime type was successfully served over Apache web server.

[scanny]

I'm pretty sure the MIME type for .pptx files is application/vnd.openxmlformats-officedocument.presentationml.presentation. The one you mention above is appropriate for the older .ppt files.

Does your Apache instance have a MIME mapping explicitly for the .pptx extension?

On the file call, I think you might mean file -I test.pptx, equivalent to file --mime test.pptx. On my machine (Mac) this returns application/zip; charset=binary for all Microsoft Office files.

[dskrad]

I'm not sure about the difference between older and newer office documents in regards to the MIME type.

My Apache instance does have entries for the newest office document versions (exactly as you stated above).

You are correct about
file -I
This is the Mac implementation of file

But on Linux, Ubuntu and Raspbian, it is
file -i

I did a bit of research about MIME types (aka Content type) and "octet-stream" is the default catch-all type assigned when none is explicitly set. I didn't find any way to explicitly set the type so I'm not sure this is a bug. But maybe some python or office document guru may have the answer.

Thanks for the awesome module!! It is really powerful and useful.

[scanny]

Are you serving the file directly from a stream, like StringIO or bytes[]? When you do that sort of thing you have to set the Content Type: header in the response to the proper MIME type yourself. At least I always have.

If it's a file on the hard drive with a .pptx extension and Apache isn't applying the registered MIME mapping I'm afraid I'm out of ideas :)

Glad you find the module useful :)

[dskrad]

So far, as it stands, the Apache server is applying the appropriate "application/vnd.openxmlformats-officedocument.presentationml.presentation" mime type. I can download the pptx with a desktop browser (Chrome) and I am getting the right response header (mime type) in the developer console. The only issue is that when I try to open the file with mobile Safari (iOS 7) the pptx never actually downloads or opens. 
Thanks for all your help. I will do more extensive testing and let you know what I find. I would ultimately like to use your module in a script which will generate a pptx file and then serve it up over http (either apache or directly -- I use woof.py for convenience when going from my Ubuntu desktop or raspberry pi (raspbian) to my Mac). I am not sure what the issue is. 

[scanny]

I think the key question will be does it behave differently with a .pptx file that is saved by PowerPoint itself and one that is generated by python-pptx.

If there is no difference, the problem is elsewhere, perhaps on the web server.

If they do behave differently, you can use opc-diag to compare two versions of the same file, the one generated directly by python-pptx and the same file loaded and saved by PowerPoint and that should identify the difference. If there is a difference we can bring them to be consistent.

[scanny]

Hi David, I actually have a pretty good idea what the diagnosis is for the original problem, not opening in Keynote, I expect Apple uses the same code to open it in iOS, so I expect the same update will fix both problems. It sounds like the MIME-type problem is put to bed, so I'll leave scope on this one to the original problem.

It might be a little while before I get to this one, so if you want to dig in yourself for a temporary fix let me know and I'll share the gory details :)

[dskrad]

I would be willing to try and help. Let me know what you think may be the root of the bug. Thanks.

[scanny]

@dskrad Okay, I was digging into this to identify where to point you and actually identified the problem in the process. Two new lines of code do the trick to fix it on my side. For whatever reason, Keynote is insisting on the presence of a <p:clrMapOvr> element that is optional according to the spec. Whatever :) I'm happy to oblige in the spirit of platform inclusiveness. Besides, Apple has been pretty good to me over the years :)

Are you able to test it if I push a fix to GitHub? I'd prefer not to push a new PyPI release until we can verify the fix.

[dskrad]

I am willing to test new version. I would have to first pip uninstall python-pptx then pull from the repository and run setup.py? If I am wrong let me know. Sorry, but I am still novice in some ways regarding python.

[dskrad]

Wow. I just added those tags to my "broken" file and ran

opc repackage broken clr_fix.pptx

and all is well.

Keynote will open and import, I can open with Preview on my Mac, and I can download and preview on my iOS device. Pretty wild. I guess the mime type issue was a red herring.

Thanks! Waiting for the commit.

[dskrad]

In the name of simplifying, I found that just by adding the self closing tag <p:clrMapOvr/> fixed it as well. No need to actually define anything between two tags.