-----Original Message----- From: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] On Behalf Of Jared Williams Sent: 16 September 2008 16:31 To: 'Wikimedia developers' Subject: Re: [Wikitech-l] SVG conversion options -- rsvg vs Inkscape?
-----Original Message----- From: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] On Behalf Of Nikola Smolenski Sent: 16 September 2008 15:35 To: Wikimedia developers Subject: Re: [Wikitech-l] SVG conversion options -- rsvg vs
Inkscape?
Aryeh Gregor wrote:
On Tue, Sep 16, 2008 at 8:14 AM, Jared Williams jared.williams1@ntlworld.com wrote:
See no reason why svg isn't precompressed with gzip, and
given a svgz
extension.
It's still 188K gzipped. The 22x13px PNG used in
[[Bethlehem]] is 300
bytes, close to 1000 times smaller. Some way to compress SVGs *lossily* is clearly needed here.
Philosophically, it shouldn't be done. Someone might want
to print a
Wikipedia article on a building, and the 500K flag would then look just right.
Pragmatically, if you don't care about printing articles on
buildings
and are ready to lossily compress SVGs, there is no
particular need to
use SVG when PNG will do.
Otherwise, the idea of lossily compressing SVGs is very
interesting,
and I believe it could be done :)
Not sure. Obviously working out the most effiecient stylesheet for a given svg, removing repeated style attributes would be one area. But might effect the editability of the image. It could be like trying to edit a minified javascript file.
Producing a smaller SVG thumbnail of a SVG image would definitely be possible. Looking at Flag_of_Mexico, almost all the coordinates have several decimal places, so could reduce the accurancy of those in a smaller image without loosing anything.
Jared
Actually seems a SVGCrush is in progress..
https://code.launchpad.net/~ted-gould/+junk/svgcrush-delivered
Jared