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] ZIP specification for ODF 1.2

On Monday 26 October 2009 02:35:44 Leonard Mada wrote:
> But then again, I would argue that ODF should support at least tar.
> Tar is uncompressed, but it is standardized in POSIX.
> It may have some disadvantages, but at least it is standardized.
> [http://en.wikipedia.org/wiki/Tar_%28file_format%29]
This is a bad idea. The format is unsuitable for this task, because of the way 
it is designed to work (i.e. streamed off tape).

> I may want to have later support for other algorithms,
> though I believe something standardized is primordial.
I don't understand the use of "primordial" to mean anything sensible in this 
context. Perhaps you can explain / clarify?

> TAR allows saving all files (streams) into a single file,
> so no problems arise if the document is passed between
> different users. There might be issues with UNICODE names,
> though I believe that ODF does not include unicode names
> (please correct me if I am wrong), and there are problems
> with with random access within the file.
Lack of random access is a showstopper here.
> As an advantage, you could readily compress the tar archive
> using any common algorithm like those mentioned on Wikipedia:
> http://en.wikipedia.org/wiki/Data_compression
This will make the problem worse, not better.

> Even more powerful algorithms may arise in the future,
> so I would not want to limit ODF to an algorithm of the past
> [in 10 years it may be well of the past, e.g. Acrobat seems to
>  use a different and better algorithm - though I do not have
>  any data to back this up].
This is not a meaningful comparison. PDF is not ODF, although the compression 
algorithm may not be different (e.g. both could be using Deflate).
> I would rather want to have additional options to use when
> compressing the ODF package.
As an implementer, less options are better. After all, we're all going to have 
to do zip anyway.

The problem with lack of a standard for zip archiving is really a 
standardisation lawyer issue, not an interoperability issue. I'd like a better 
document too, but there are a lot more important things to work on.


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