> A while ago, someone raised the possibility of recompressing PNG files.
It turns out that since recently, some crazy googlers are guilty of "zopfli"
which can optimize PNGs even better, but taking all the CPU in the world for
doing so. This doesn't sound useful for automated use during package
builds, but can be great for one-shot use.
Where an image is static (as opposed to being generated at runtime), in the
order of utility and efficiency:
upstream > source packages > binary packages
But then, upstream is outside your control, and you often want to use
unmodified upstream tarballs. In such cases, build time is it.
I wonder what's the best way to do so. The recommended way to optimize PNGs
is going to change: today, I nominate optipng -o4 -i0 -fix "$@" && advpng
-z4 "$@", but tomorrow we can expect optipng's upstream to integrate
advanced deflate, googles to come up with ultra-fast zopfli2, pngcrush
deciding they don't like to be upstaged, etc.
So my idea would be to have a token package with nothing but:
(git ls-files || find -type f)|grep -i '\.png$'|xargs -d '\n' ...
and Depends: on this week's best optimizer.
Is this sane?
Asking for a debhelper addition could be better but can't be used to specify
dependencies.
--
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130528112609.gc22...@angband.pl
