On 29/08/12 15:01, Jon Dowland wrote: > On Tue, Aug 28, 2012 at 12:56:47PM +0200, Vincent Lefevre wrote: >> Before wondering whether PNG files should have an additional >> compression level, is there any reason why a better PNG compression >> isn't used in the first place? For instance, "optipng -o9" tries >> various parameters and keeps the best one. > > So recompress upstream PNGs and suffix +dfsg to the source version? There > might > be some disadvantages to this. If you are using VCS to manage the package, you > are probably carrying the upstream PNGs in that already, so there's an > appreciable increase in repository size to carry the optimized PNGs too. > Another approach could be to inject optipng into the build process and treat > the outputs like compiler output (packed into binary packages, thrown away on > clean), but then repeated builds could be CPU-expensive. Perhaps getting > upstream to carry better-compressed PNGs in their next release is a good idea. > >
Better to create a dh_ plugin to do this. I think there is something like that already floating around for PNGs, at least on Ubuntu the pkgbinarymangler does re-compress all PNGs. I don't think it's worth +dfsg, and CPU cycles will only be wasted once on the maintainer side, since most of PNGs are in arch:all packages anyway. -- Regards, Dmitrijs.
signature.asc
Description: OpenPGP digital signature
