For the last couple of years, this wasn't a killer problem because my Debian servers were still ticking along on the OO 2.4 branch. That is no longer the case, Debian has moved Open Office to 3.2 and now this little problem has the potential to force me into a rewrite of 5 years of coding.
The problem:
An .odt file created using this module will give a warning when opened with Open Office 3.2. "This file is corrupt, do you want me to fix it?"

When I am using X directly, I can just click 'yes' and everything is okay. The structure of the document is not harmed, or even visibly changed from the way it appeared in OO 2.4.

The BIG problem is that I am not using X, I am running this on a production web server and there is no way (that I can think of or want to contemplate) to click that little 'yes' button programmatically so that the file can be converted to a PDF.

1) Anyone else experiencing this problem? I will be happy to post a link to an example .odt file. I HOPE this is just me, that means there is something I can change, but this error is occuring on 3 separate machines.
2) Is there any way to fix this?

Thank you,
Richard Still (oakbox)

oodoc_test does produce a file that can be opened in 3.2 without error.

Unfortunately, a document created with some of my scripts continue to fail in 3.2 and can be opened in 2.4 without error.

I will take apart the offending document and look for where, specifically, it is failing.

-oakbox

Looks strange. I pasted you code unchanged in the program below.
I used a source file containing nothing but an empty table named "blockgraphic".
Then OpenOffice doesn't complain with the resulting file. (I currently use OOo 3.3.0 build 9567 from the official OOo distribution).
However, when you import an image through createImageElement it's a good idea to update the file manifest accordingly. In your script, a "file.png" external resource is physically imported but not declared in the manifest, so the resulting ODT file is not strictly OpenDocument-compliant, and OpenOffice could legitimately warn (while it doesn't in my installation). The two lines before the save() instruction in my example show a way to set the appropriate image/png entry (the imageLink method retrieves the internal path of the image file in the ODT file and the user must provide the MIME type).
Then if OOo complains again even if your manifest is OK, I really don't see where is the issue.

Good news... However you should never have to save, reload and save a file to update the document content and the manifest separately. It undoubtedly works but it's counter-performing because the physical file is saved twice. When several document parts are connected to the same container, the save() method of one of the parts makes all the changes persistent. In the example below, $meta and $manifest are connected to the same container as $document, and the last instruction saves all. Of course, the 'container' parameter of each secondary part must be set to the primary document object and *not* to the filename!

http://www.rattan-hoefner.de/