OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [office-comment] OpenDocument Package : add LZMA compression algorithm


That's an interesting suggestion.

I can't speak for the TC, but I do have some observations about the current choice of compression algorithms and addition of LZMA.

 1. The Current specification is based on the PKWARE APPNOTE 6.2.0, which does not use LZMA.  This is the version of Zip supported by all implementations of ODF.  It is supported in common with the OOXML package format, OPC.  6.2.0 is supported in operating systems as a built-in form for compressed folders.  Finally, APPNOTE 6.2.0 has been profiled at ISO/IEC JTC1 for reference in international standards.  EPUB appears to be taking the same approach.

 2. The DEFLATE method is *required* in the creation of encrypted ODF 1.2 Packages. (This is an ODF-unique encryption methodology that is not any specified by PKWARE.)  This may apply for EPUB also.

 3. PKWARE APPNOTE 6.3.0 and later do specify LZMA as an available compression algorithm.  However, no definitive reference is provided and the algorithm is not specified in any APPNOTE.  

 4. The specification of LZMA and its reference implementation are in the care of Igor Pavlov, <http://7-zip.org/sdk.html>.  Although that page specifies that the SDK is in the public domain, it would take more than that, I think, to make a public specification and have it be curated in a manner that would satisfy the requirements for incorporation in a public standard, especially at ISO/IEC JTC1.

 5. Finally, to provide compatibility with legacy documents and software, it is likely that any use of LZMA would be introduced as optional and DEFLATE would remain the default case.  LZMA might be eligible for optional use (and only in ODF 1.3 documents, say).  To maintain interoperability, that means ODF 1.3 consumers would have to accept either.  

 6. It would have to be determined whether the savings in the case of ODF packages is enough to justify the potential disruption of having incompatibly-compressed ODF documents out there.  I have no helpful information about that.

I don't have any idea how worthwhile LZMA is for ODF and how the ODF TC and implementation teams would give it priority relative to other features that are being called for.

These are, I think, the considerations that need to be reconciled in adding LZMA to ODF packages.


 -- Dennis E. Hamilton
    dennis.hamilton@acm.org    +1-206-779-9430
    https://keybase.io/orcmid  PGP F96E 89FF D456 628A
    X.509 certs used and requested for signed e-mail



-----Original Message-----
From: Jérôme Bouat [mailto:jerome.bouat@wanadoo.fr] 
Sent: Wednesday, August 20, 2014 15:37
To: office-comment@lists.oasis-open.org
Subject: [office-comment] OpenDocument Package : add LZMA compression algorithm

Hello,


The below document specifies that an OpenDocument Package is a zip file. Each file contained in the zip file "shall be non compressed (STORED) or compressed using the 'deflate' (DEFLATED) algorithm" :

http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part3.html#__RefHeading__752789_826425813

New versions of zip archive software support now the "LZMA" compression method in zip archives : 7-Zip since 2010, other free software (PeaZip, ...) and proprietary software.

The decompression speed of "LZMA" is quite the same than "deflate" but it offers a better compression ratio in most cases (especially with XML content) and seldom a worse compression ratio. During decompression, the used memory is lower than during compression.

The compression with "LZMA" is slower than with "deflate" and the required memory of the compression increases with the dictionary size. However the dictionary size still be small in many cases because the zip format compresses separately each member of the archive (one dictionary per member). Moreover, a computer has now many processing units (multi cores, ...) and thus enables parallel compression (for example : a compression process of one archive member per processing unit).

If you want to limit the required memory of compression/decompression, you can specify a maximum LZMA dictionary size.

Do you think this feature could be added to the next specification ?


Regards.

-- 
This publicly archived list offers a means to provide input to the
OASIS Open Document Format for Office Applications (OpenDocument) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: office-comment-subscribe@lists.oasis-open.org
Unsubscribe: office-comment-unsubscribe@lists.oasis-open.org
List help: office-comment-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/office-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office
Join OASIS: http://www.oasis-open.org/join/



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]