This article was nominated for deletion on 2006 August 19. The result of the discussion was keep.

Format internals -> content.xml[edit]

This XML snippet seems rather weird:

<text:h text:style-name="Heading_2">This is a title</text:h>
<text:p text:style-name="Text_body"/>
<text:p text:style-name="Text_body">
   This is a paragraph. The formatting information is
   in the Text_body style. The empty text:p tag above
   is a blank paragraph (an empty line).
</text:p>

Since all the elements are in the namespace referred to by the text prefix, it is unnecessary to explicitly use the prefix on the attributes as well. Is this really how OpenOffice writes the XML files? This would be the simplest and most appropriate:

<text:h style-name="Heading_2">This is a title</text:h>
<text:p style-name="Text_body"/>
<text:p style-name="Text_body">
   This is a paragraph. The formatting information is
   in the Text_body style. The empty text:p tag above
   is a blank paragraph (an empty line).
</text:p>

update - this goes for meta.xml as well.

Daniel Schierbeck 09:55, 7 February 2006 (UTC)[reply]

Here’s an extract from a NeoOffice 1.2 (OO 1.1.5) which verifies the example (as to efficiency, I can’t answer that…) I created a new text document and set the first paragraph to heading 2. Line breaks in the XML are mine:

 <text:h text:style-name="Heading 2" text:level="2">This is a title</text:h>
 <text:p text:style-name="Standard"/>
 <text:p text:style-name="Standard">This is a paragraph.</text:p>

Barefootguru 18:30, 7 February 2006 (UTC)[reply]

merge with OpenDocument/Specifications[edit]

A sub-article in the main article OpenDocument/Specifications may do the job of keeping the main article within reasonable size. Louie 19:13, 29 May 2006 (UTC)[reply]

Page name[edit]

This page was moved from OpenDocument technical specifications to OpenDocument Specification without any discussion, as far as I can tell. I think the new name is vaguer and does not conform to the MoS. Wmahan . 18:01, 1 June 2006 (UTC)[reply]

Thanks for fixing it (it's OpenDocument technical specification now). Wmahan . 19:26, 3 June 2006 (UTC)[reply]

Neither page brings up the article now. 9point9 20:30, 17 September 2006 (UTC)[reply]

Not enough context?[edit]

Does anyone know why this article was tagged as such? Shinobu 07:06, 2 July 2006 (UTC)[reply]

Please work from the spec.[edit]

I've changed a number of details on this page; one of which was out-of-date, but the rest of which were factual errors. Please base comments about OpenDocument on the standards document itself, rather than the output of OpenOffice.org, wherever possible. AlexHudson 10:42, 26 July 2006 (UTC)[reply]

On including limitations[edit]

User:HAl included some text about not being able to put tables into presentations without "raw text or embedding spreadsheets", I assume based on the comments of Brian Jones. This doesn't make sense within the context of the specification, and isn't correct. The issue at hand with tables is that they're not supported as drawable objects. I've updated the text to reflect this.

Please, do bring across limitations highlighted by OpenDocument critics, but please ensure that they're accurate - this is an article on the technical specification, not on the criticisms levelled at OpenDocument. There is a subtle difference there ;) - AlexHudson 22:53, 19 August 2006 (UTC)[reply]

Zip Standardization[edit]

The article states:

It is known that many programs which implement the OpenDocument format do not utilise high compression levels. Users can therefore optimise the file sizes by using more aggressive compression-programs. This may be coupled with a number of image optimisation programs being used on the contained pictures and has been seen to give over 40% reduction in file size over a file directly saved from an OpenDocument compatible program.

but earlier in the article, there is a mention of a specification of (a single?) ZIP format.

While I believe both statements are accurate, I believe this requires explanation. How is it that a single ZIP format can specify different compression levels? This is based on the principle of least surprise. That is, the default model people have of file formats is that they are unique specifications. 70.247.174.86 (talk) 15:29, 25 June 2010 (UTC)[reply]

Yes, many file formats give a (more or less) unique representation of a given document.

But OpenDocument and other DEFLATE-based formats, such as Portable Network Graphics and .tar.gz and JAR file, are not like that.

Many data compression formats -- and in particular, the DEFLATE algorithm usually used in the ZIP (file format) -- can represent a particular document in thousands of different ways. (Every one of those ways, when decompressed, will give an output file that is bit-for-bit identical to the original input file and to each other).

How is it that a single ZIP format can specify different compression levels?

Pretty much every ZIP compressor allows the user to specify different compression levels -0 through -9 -- see DEFLATE#Encoder/compressor and Portable Network Graphics#DEFLATE optimization.

Apparently, according to the section you quoted, many programs use some compression less than the -9 option.

How is it possible that thousands of different valid compressed files, of many different sizes, can be decompressed with a single decompressor using a single algorithm -- in particular, DEFLATE -- and produce thousands of bit-for-bit identical copies of the original files? Why is DEFLATE compression not bijective? Why doesn't everyone use the maximum -9 compression? Those are fascinating questions.

But perhaps a better place to ask that question is at Talk:Lossless data compression or Talk:ZIP (file format), because it applies to all DEFLATE-based formats and many other compressed file formats, not just OpenDocument files.

--DavidCary (talk) 04:04, 8 July 2011 (UTC)[reply]

Why doesn't everyone use the maximum -9 compression?

Short answer: compression level 9 takes longer.

Longer answer: Having the smallest possible file size might be important to some users, but it will take longer _every_ time you save the file and _every_ time you read the file. There is a tradeoff. Also other files in the archive such as PNG files are already compressed, there is very little benefit from compressing them again.

While some readers are passionately interested in compression and getting the smallest possible file sizes, I do not think it is appropriate for Wikipedia, especially not a Wikipedia article that is supposed to be about the OpenDocument technical specification, I think it is offtopic here.

The article on DEFLATE only very briefly mentions compression levels, that article might be a place to include more information about the various compression levels. -- 109.79.79.250 (talk) 16:23, 4 December 2014 (UTC)[reply]