Document 'corrupt' for LibreOffice, opens fine with other OOo-based software

users
#1

You should be able to delete all of Configurations2/..., Thumbnails/thumbnail.png, and manifest.rdf without any harm whatsoever, so long as the related <manifest:file-entry> elements are deleted from META-INF/manifest.xml.
You should probably *not* keep the settings.xml if you are creating a different content.xml file (just in case).

You might check on consistency of version attribute occurrences and their values. For ODF 1.2 documents, it is expected that there will be a consistent use of "1.2" in a variety of places. If there are any missing version attributes or ones with conflicting values of "1.0" or "1.1", that might be a problem as well.

This is a bit trickier. What version of ODF are you specifying in your "template" and the subsequent manipulations?

It could be none of these that are derailing LO. It could be some sort of problem being caught in the resolution of styles, or some problem where automatic styles are involved.

SOMETHING ELSE TO TRY

When LO says the document is corrupted, do you have an option to attempt "recovery" or "repair"? When you exercise that option, can you save the result and reopen *that* successfully in LO ? I think you have done this according to your other report.

If that works, you then need to figure out what it is that is different in the repaired one and the one that was declared corrupt. Look at the manifest and the files that are present, and in the root element opening tags for styles.xml and content.xml. (Notice the office:version attributes and any manifest:version attributes as well.) Check to see whether automatic styles were added to content.xml where there are none (?) for your "corrupted" document.

- Dennis

#2

I should mention that on any Save [As ...] LO will automatically generate new Configuration2/..., Thumbnails/thumbnail.png, manifest.rdf, and settings.xml files along with the others. I think it is differences elsewhere that will be clues to the problem.

It also helps if you can determine the most-recent version of LO that does *not* treat your document as corrupt.

- Dennis

#3

To All:

Document opens without error using OOo2.4.1.
Save the file.
File now opens in OOo3.2.1 & Libo3.5.3.2 without error. (Did not before)

#4

You should be able to delete all of Configurations2/..., Thumbnails/thumbnail.png, and manifest.rdf without any harm whatsoever, so long as the related <manifest:file-entry> elements are deleted from META-INF/manifest.xml.
You should probably *not* keep the settings.xml if you are creating a different content.xml file (just in case).

OK, I'll try that.

You might check on consistency of version attribute occurrences and their values. For ODF 1.2 documents, it is expected that there will be a consistent use of "1.2" in a variety of places. If there are any missing version attributes or ones with conflicting values of "1.0" or "1.1", that might be a problem as well.

This is a bit trickier. What version of ODF are you specifying in your "template" and the subsequent manipulations?

The "template" document is a regular ODF document, created either with LO or OOo or any other OOo-based software, so there shouldn't be any inconsistency between the versions. I also took care to copy the office:document-content opening tag from the existing content.xml in the template, so I guess that shouldn't be a problem either, unless there are other references to the version elsewhere, but I didn't find any.

It could be none of these that are derailing LO. It could be some sort of problem being caught in the resolution of styles, or some problem where automatic styles are involved.

SOMETHING ELSE TO TRY

When LO says the document is corrupted, do you have an option to attempt "recovery" or "repair"? When you exercise that option, can you save the result and reopen *that* successfully in LO ? I think you have done this according to your other report.

Yes I did. And the repaired document is correct. I've been comparing the original document with the repaired one and tried to change the generation to make the one we're creating as close as possible to the one LO saves. But it's still failing…

If that works, you then need to figure out what it is that is different in the repaired one and the one that was declared corrupt. Look at the manifest and the files that are present, and in the root element opening tags for styles.xml and content.xml. (Notice the office:version attributes and any manifest:version attributes as well.) Check to see whether automatic styles were added to content.xml where there are none (?) for your "corrupted" document.

I've seen there were indeed some declarations for automatic styles in the document contents, but I must say I don't know ODF enough to understand what these are. Basically, all the document contents should use the styles defined in styles.xml without any modification at all. Are automatic styles needed in this context?

Thanks a lot for all the hints.
  - Eric -

#5

To All:

Document opens without error using OOo2.4.1.
Save the file.
File now opens in OOo3.2.1 & Libo3.5.3.2 without error. (Did not before)

Yes I had tried that too and I saw it was working indeed.

------------------------------------------------------------------------------------------------------------------------
Examining meta.xml in original file:
<meta:generator>OpenOffice.org/2.0$Linux OpenOffice.org_project/680m1$Build-8990</meta:generator>
--------------------------------------------------------------------------------
At http://odf-validator.rhcloud.com/, the original file fails:

Ah! Now that's what I needed. Didn't know this service existed, this will help a lot! Thank you very much for the pointer.

The document is NOT conformant ODF1.0!

Details:

doctest.odt/META-INF/manifest.xml: Error: The file 'Configurations2/accelerator/current.xml' shall not be listed in the 'META-INF/manifest.xml' file as it does not exist in the ODF package 'doctest.odt'!
doctest.odt/META-INF/manifest.xml: Error: The file 'Thumbnails/thumbnail.png' shall not be listed in the 'META-INF/manifest.xml' file as it does not exist in the ODF package 'doctest.odt'!
doctest.odt: Info: Generator: OpenOffice.org/2.0$Linux OpenOffice.org_project/680m1$Build-8990

OK, I've been changing the manifest.xml file to reference only the files that actually were in the document and it got better. But now I have an error that I don't understand:

doctest-bis.odt/mimetype: Error: There shall be no extra field for the 'mimetype' file of ODF package 'doctest-bis.odt'!

What does that mean? The contents for the mimetype file is just:
application/vnd.oasis.opendocument.text
What's wrong with that? Or is the error elsewhere?

BUT: the document now opens in LO 3.5.4 without being reported as corrupt! So, I guess the problem is solved, even if I'd like to know anyway what the error above means.

Thank you so much again, and to all who helped!
  - Eric -

#6

For the record, here is what I had to do:
Put the mimetype file in the archive at the first position. This seems to be mandatory in any ODF file.
Delete the settings.xml file from the archive, as it seems it is not really needed and can cause some problems.
Write a correct META-INF/manifest.xml file, referencing exactly all the files in the archive and no other.
Make sure all opening tags for all XML documents included the same ODF version. That was quite easy in my case, since I just had to copy the version from the template document.
With all this, the document opens without problem in all versions of all OOo-based software we could test (including LO 3.5.4, IBM Lotus Symphony 3.0.0 FP2 and OOo 3.1.1).

Looking back at it, it is actually quite surprising the former versions opened the file without any warning, since the META-INF/manifest.xml file in it was completely wrong. The newer versions really seem to do the right thing here.

Thanks a lot again to all who answered.
  - Eric -

#7

Hi :slight_smile:
Errr, LibreOffice and most other programs that use ODF natively uses ODF 1.2 now.  The 1.1 is really "old hat".  It's the one that MS uses although they have promised to use 1.2 in their new release (the one after MSO 2010)
Regards from
Tom :slight_smile:

#8

Hmm,

The META-INF/manifest.xml file does require a <manifest:file-entry> element that has manifest:full-path="/". It also requires a manifest:media-type attribute whose value matches the string in the package's mimetype. E.g., manifest:media-type="application/vnd.oasis.opendocument.text".

In addition, but only for an ODF 1.2 document, there should be a manifest:version="1.2" on that <manifest:file-entry> element and also on the <manifest:file-entry> for the content.xml part. (In that case, there must be office:version="1.2" attributes on the root elements of content.xml, styles.xml, and meta.xml I believe. Check whether these are on the versions of the file that are not reported as corrupted and follow suit.

Finally, how are you producing the mimetype in the Zip package? It might be better to let LO do that.

- Dennis

#9

Correction:

The required manifest:version="1.2" is required, for ODF 1.2 documents, on the <manifest:manifest> element (the root of META-INF/manifest.xml> and on the <manifest:file-entry> having manifest:full-path="/".

Also, double-check all places where MIME Type strings are expressed, including in the mimetype file of the package. There should be no ",", ";" or whitespace characters in the content values.

- [;<).

#10

Correction:

The required manifest:version="1.2" is required, for ODF 1.2 documents, on the <manifest:manifest> element (the root of META-INF/manifest.xml> and on the <manifest:file-entry> having manifest:full-path="/".

OK, LO does open the document without it, but I'll put it in there anyway, wouldn't want it to break for other software.

Also, double-check all places where MIME Type strings are expressed, including in the mimetype file of the package. There should be no ",", ";" or whitespace characters in the content values.

Just copied the exact values from an existing file, so these should be OK. Only need 3 actually: application/vnd.oasis.opendocument.text for the document itself, text/xml for all XML files and image/png for the images.

As for your previous question:

Finally, how are you producing the mimetype in the Zip package? It might be better to let LO do that.

I'm not producing it, I'm copying it from an existing ODF document, so there shouldn't be any problem at all. I'll make sure the type written in it is actually the type written in the manifest.xml file for the root document though.

Thanks a lot!
  - Eric -