LiveCD optimisations explained

[Louis Simard]

At 2001-05-21 14:48 GMT, Phillip Susi <psusi at cfl.rr.com> wrote:
> When attaching scripts please make sure they are attached with an inline
> disposition so they are readily reviewable while reading the email
> instead of having to save them and open them in another text editor.

Err... While I know what you want me to do (you want
Content-Disposition: inline), I don't know how to do that in the Gmail
web interface. Perhaps I'll set up Mozilla Thunderbird, if it can do
that :-)

> [C]ould you explain a bit what you mean by "optimizations"?  You can
> of course, use a higher lossy compression on the png images, but that
> lowers their quality, which I think is not a desirable tradeoff.

The optimisations I describe would be completely lossless, barring
bugs in the software used to carry out these optimisations.

- For PNG: the data used to store some images on the CD is not
compressed to the highest level. OptiPNG takes those files and tries
to recompress them to the highest level, while ensuring that every
pixel's color value ends up being the same.

- For SVG: the data used to store ALL images on the CD is not optimal
for rendering purposes. Inkscape metadata, Sodipodi metadata, ID names
for elements that end up unused, gradients defined dozens of times,
etc., are bloating the files. Scour.py takes those files and removes
this bloat, while ensuring that the new versions render identically to
the original. However, since Inkscape's metadata ends up removed, it
could be more difficult for users to open these new files in Inkscape.

- For XML, as described by Martin Owens: xmllint would remove
everything superfluous from all files on the CD, while ensuring that
the data is parsed identically. I haven't tested this yet except on
one file from the CD (squashfs ->
/var/lib/gconf/defaults/%gconf-tree.xml), but that file went from
2,095,034 bytes to 1,779,376 (a savings of 315,658). There's more hope
yet.

Regards,
- Louis