Optimising OpenDocument file sizes

[9point9]

As the OpenDocument format is simply a set of ZIP'd files it is easy enough to extract and modify the files then recompress it. This may result in smaller file sizes which while not an issue for local files, is very important for files on the Internet and being emailed. This is a test that I've done which may be of use:

Original file
I downloaded version 1.23 of the OOo 2.0 setup guide from CVS:
http://documentation.openoffice.org/source/browse/documentation/www/setup_guide2/2.x/en/Attic/
File size: 868141
And when uncompressed...
Contents size: 1111415

Recompressing on maximum
It's widely known that OOo does not compress with the "Maximum" setting so the simplest thing to do is to recompress the extracted contents with a ZIP utility setting it to maximum. Doing this with Ontrack Powerdesk 5.0 resulted in the following:
File size: 735189

That's a 15% reduction. A couple of notes on this:
1. Don't use Windows XP's built in compression tools
2. Don't allow your OS to insert thumbnails, indexing files or anything like that in (you may not see them as they may be hidden but they'll be compressed)
3. Remember to enable paths in the ZIP file
4. You must include everything!

Optimising images
Many images are stored in the OpenDocument pictures subdirectory in PNG format. OOo does not produce optimal PNG files (nothing does) and the file sizes can be optimised without loss of quality. This has been discussed recently:
http://www.oooforum.org/forum/viewtopic.phtml?p=106214#106214
What I tried with the original file was to run PNGCrush on the pictures and thumbnails subdirectories with the Open Document file:
http://pmt.sourceforge.net/pngcrush/

Running the DOS MMX build of PNGCrush with

[9point9]

As an improvement i tried rezipping under Linux from the command line with:

[9point9]

I've now used jpegoptim to reduce the size of the JPEG files losslessly. This isn't effective on all JPEG files but can give over 10% reduction on some.

I used it on the original file with:

[9point9]

I have now posted a Linux shell script that accomplishes all this in the Code Snippets Forum:
http://www.oooforum.org/forum/viewtopic.phtml?t=27452&highlight=

This gives the same output size: 677642

A DOS/Windows batch file to accomplish this would also be possible.
_________________
Arch Linux
OOo 3.2.0

OOoSVN, change control for OOo documents:
http://sourceforge.net/projects/ooosvn/

[oiaohm]

Under Linux or windows advancecomp to repack the Zip http://advancemame.sourceforge.net/comp-readme.html

It uses 7z better code for doing the compressing in side zip files than even zip -r -9.*

I don't know how advancecomp png compress compares to pngcrush.

I would love to see the deflate from 7-Zip implementation in openoffice it is far better.

[ace_dent]

For some quite geeky information on crushing every last byte out of PNGs, I have written this guide (with batch scripts available). I noticed that 'pngcrush' was still being used and would recommend at least switching to the modern replacement OptiPNG.

Regards,
Andrew

[zero0w]

Curiously, I found that recently the file size of ODT files saved by OOo 2.0.2 is 40% smaller than that of OOo 1.9 m125 (2.0 Beta 2).

It looks like there are some optimization works going on between these versions.

[9point9]

I've had a go at using optiPNG as suggested. This gets the draft setup guide file used previously as small as 669518 bytes. I've incorporated this into my shell script too, check the link in my siggy.

I can probably push it further by brute forcing the zlib compression window. Then it might take all day!

[9point9]

AdvancedCOMP does give quite an improvement. Running advpng before optipng and advzip at the end gives the best compression so far. The setup guide file now compacts to 661082 bytes. That's a 23.874% reduction.
_________________
Arch Linux
OOo 3.2.0

OOoSVN, change control for OOo documents:
http://sourceforge.net/projects/ooosvn/

[9point9]

I've now used OptiPNG with different sizes of zlib window. I've used all 7 available between 512 and 32k. This means I've now got the setup file size down to 660810 bytes. That's a 23.905% reduction in size from the original.

The downside of this is time. It now takes 2 hours on this complex file. This is all for the purpose of experimentation though so that perhaps soemthing useful can come out of it in the long run.
_________________
Arch Linux
OOo 3.2.0

OOoSVN, change control for OOo documents:
http://sourceforge.net/projects/ooosvn/

[9point9]

A major improvement that can be made is by using progressive compression in JPEG's. Progressive JPEG's are supported by any modern web browser, decent graphics pakcage or office suite will display them.

When you see an image on a web page incrementally increase in quality as the page loads, that is because it uses progressive compression. It takes more power but can be slightly smaller and gives the low quality image, increasing in quality which helps on web pages.

By default it seems like most JPEG's don't use progressive compression, I think because many output programs don't use it or don't use it by default. It is available in GIMP as an option for instance.

When converting a JPEG to use progressive compression, we can then use a non-progressive program to try and improve the size, this results in which ever method is smaller being used. I have seen ~3% coming off JPEG files this way.

By implementing non-progressive > progressive > non-progressive processing to JPEG's in the sample file, I have been able to knock off another 18k from the file size, losslessly again. The file size is now 642484 bytes. A 26.016% reduction compared to the original file.
_________________
Arch Linux
OOo 3.2.0

OOoSVN, change control for OOo documents:
http://sourceforge.net/projects/ooosvn/

[ace_dent]

Re-saving a jpeg as you describe results in lossy compression. This accounts for the savings you are seeing. Progressive jpegs aren't saved by default in most programs, as there is extra file overhead for this. Although you will probably get a similar file size (normalk Vs progressive), the extra bytes taken means your image is lower quality. Try doing some visual compraisons.

Regards,
Andrew

[9point9]

[pitonyak]

Luckily, spending more time creating better compression only affects the creation, and not the reading of the file (for speed).
_________________
--
Andrew Pitonyak
http://www.pitonyak.org/oo.php

[9point9]