TM->BH: This is a wish for an enhancement, please have a look, thanks !

TM->BH: This is a wish for an enhancement, please have a look, thanks !

do you mean this to change the info zip ? 

I think it is good idea to change it if it is opensource, fast and
have no problem with OOo

The site is down at the moment, but I am 99% sure that LZO uses it's own
compression algorithms and file formats that are not ZIP/GZ/Deflate compatible.
Therefore, files created with this library would not be compatible with older
versions of OO.
Also (AFAIR) LZO is designed to be fast and use very little memory for
decompression, generally at the expense of compression ratio, so I doubt the
files would be smaller than with the current implementation.

I think this should be WONTFIX or INVALID..

(bzip2 would be a better option for improved compression in OO)

faster decompression is the point: the compressed sizes will only be slightly 
different if at all making basically no impact on todays hdds but the 
decompression is faster, so load and save times will be faster which I thought 
more important. On the other hand: why hasten and not let it take time? work 
using the new compression api might be more than what is gained in general. But 
in general I favor fast load and save times. High compression might be achieved 
by external programs (OOo might utlize) if the user so desires. Opinions?

I also think that faster compression/decompression is more important than
smaller files. When I installed OOo in my friends PCs, they point out that file
loading/saving is noticeable slower that in MS Office. Of course I explained
them that this is due to compression, but most people I know (not PC experts)
prefer to have faster program. In fact loading files in Word/Excell isn't so
much faster, but when you load document program shows first page while next
pages are loading in background, and that looks like it load faster than OOo.
OOo can't show anything until file is decompressed, so developers should focus
on optimizing compresson/decompression algorithm.

OpenOffice.org Issue Tracker - Feedback Request.

The Issue you raised is currently 'Unconfirmed' pending review, but has not been
updated within the last 3 years. Please consider re-testing with one of the
latest versions of OOo, as the problem(s) may have already been addressed.
Either use the recent stable version: http://download.openoffice.org/index.html
or consider trying the new OOo 3 BETA (still in testing):
http://download.openoffice.org/3.0beta/
 
Please report back the outcome so this Issue may be Closed or Progressed as
necessary - otherwise it may be Resolved as Invalid in the future. You may also
wish to search for (and note) any duplicates of this Issue that may have
advanced further by checking the Issue Tracker:
http://www.openoffice.org/issues/query.cgi
 
Many thanks,
Andrew
 
Cleaning-up and Closing old Issues as part of:
~ The Grand Bug Squash, pre v3 ~
http://marketing.openoffice.org/3.0/announcementbeta.html

issue still valid. Office-file sizes are no issue. Save-Load time is though.

LZO is under GNU General Public License (GPL v2+) and is still my compression 
library of choice regarding speed.

As much as I'd also like this to be implemented, it would break compatibility.
For example, how will other apps read files made using this algorithm? A
conversion utility might be needed afterwards, and this will slowdown adoption
of OpenOffice.

This doesn't create a standard zip deflate archive - does it?
I'm fairly sure this will be a wont fix, since it would break the ODF format.
The ubiquitous zip container format was chosen for good reason...

Lowering Issue priority...

From: http://qa.openoffice.org/scdocs/ddIssues_EnterModify.html#priority 
P2 - Marks severe problems which affect a significant number of customers.
Issues with this priority must be fixed before the target release ... and should
be dealt with as soon as possible. Not fixing them for the target release is not
acceptable.

This can be forwarded to OASIS for consideration. Yes, it will cause 
incompatibility if the same extension (.odt, .ods, .odp, .odg) is to be 
preserved, unless the software had version checking (say for example: Gnumeric 
loads version .odt version 1.3, but Gnumeric only supports up to version 1.2 so 
it should/must say "File version unsupported). The easiest workaround is to add 
x to the end of the extension, a la OOXML, but personally I don't think that's 
pretty).

P/S:
As for mentioning "opening is slow due to compression", OOXML also has 
compression but from my light experiences using MS Office 2007, .docx don't take 
that long to open, so I don't think it's a valid argument.

bzip2 is a nightmare in compression time (which translates to longer save time). 
Avoid usage for frequently opened filetypes (like documents).

To grep the issues easier via "requirements" I put the issues currently lying on
my owner to the owner "requirements". 

LZO is GPL (not even LGPL) which makes it an awful choice for a standard: Apache OpenOffice would not be able to use it.

The good news though is that Google's Snappy (previously known as zippy) is faster , it's available under the new BSD license and is written in C++.

http://code.google.com/p/snappy/