Speculating successfully about svgz compression is usually hard, by the way; in real tests it can turn out that normalizing a file that uses both -90 and 270 interchangeably results in a more common keyword match, whether we normalize both to -90 or 270, as long as we normalize them at all – so try using a repository of real-world data for crunching out aggregate gains and losses using different algorithms if you're interested in good data on compression effects.
I've experienced enough peculiarities with gzip not to speculate too hard on what effect changes on input data will have on output data from gzip – like a large web page with inline normal javascript compressing to less than the same page with minified javascript, after gzipping both. (So if we ever try doing something like a special mode for producing optimally small svgz files, a gz whiz should probably look into the optimal kind and location of redundant data to inject to make the gzip dictionaries favourable for reducing end size, which is yet again another radically different problem to tackle. :) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/722544 Title: SVG transform matrix() arg order is a1 b1 a2 b2 a3 b3, not a1 a2 a3 b1 b2 b3 -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
