[Kde-games-devel] svgz in git

[Parker Coates]

On Tue, Aug 14, 2012 at 3:41 PM, Wolfgang Rohdewald wrote:
> Am Dienstag, 14. August 2012, 15:17:57 schrieb Parker Coates:
>
> there is something fishy with the timezone in your mail (this is kmail2 here)

postbox.kde.org flat out rejected my message. I tried resending it a
few times, but it was always rejected. I'm pleasantly surprised that
if got through to you at all. :) I guess it just held onto it and sent
it eventually.

>> See kde-ruleset/bin/recompress-svgz-and-png.sh. It does all the magic
>> for you. In a few cases it resulted in noticeable space savings.
>
> kde-ruleset/bin/nullgzip.py is the one.
>
> I should have browsed kde-ruleset/bin more often...
>
> Yesterday I did check the python gzip interface (you may have
> noticed I prefer python) but it explicitly says compresslevel ranges
> from 1..9. http://docs.python.org/library/gzip.html
>
> But wonderfully, level 0 does actually execute as wanted.

I was pleasantly surprised by that as well.

> i just reported that as a documentation bug.

Well done.

> I will implement that for the conversion. How can we tell the
> distributors they should recompress those files?

We should be doing it ourselves at build time via CMake. This would
require a new custom macro along the lines of "kdegames_compress_svgs(
file1.svg, file2.svg )" which would generate file1.svgz and file2.svgz
in the build directory, which we would then install with install().

> About png: I have seen so many svn commits using optipng,
> maybe that one does not help much anymore.

I think you misunderstand the purpose of the optipng stuff. Because
optipng was run occasionally, the git history contains both the normal
compressed and the highly compressed versions, essentially doubling
the amount of storage for that particular file. Running the script
recompresses the files in their original commit, meaning that the
later optipng run commits are no-ops, and only one copy of the blob is
needed.

Parker