Should we pull in someone from multimedia to help out with this?
--tomasz
On Wed, Jul 2, 2014 at 12:36 PM, Ryan Kaldari rkaldari@wikimedia.org wrote:
Actually it looks like we should disable the mergePaths plugin as well, as this makes editing most SVGs much more difficult afterwards. So... svgo file.svg --pretty --disable=removeXMLProcInst --disable=cleanupIDs --disable=collapseGroups --disable=mergePaths
I'll add this to our pre-commit hooks.
Ryan Kaldari
On Tue, Jul 1, 2014 at 5:28 PM, Ryan Kaldari rkaldari@wikimedia.org wrote:
I've been complaining lately about how our practice of running SVGs for the mobile interface through SVGO to minimize them causes lots of problems:
- Stripping the XML declaration breaks rendering in some browsers
- Stripping all the whitespace makes them very difficult to edit by hand
(which I commonly do to tweak colors or bounding boxes)
- Removing all the IDs makes them harder to edit in graphics programs that
use the IDs to label objects and/or groups.
- Collapsing all the groups also makes them harder to edit in graphics
programs.
It turns out that a lot of SVGO's behavior is configurable from the command-line. In order to minimize the issues listed above, I would like to propose that we start running SVGO with the following options within MobileFrontend:
svgo file.svg --pretty --disable=removeXMLProcInst --disable=cleanupIDs --disable=collapseGroups
Here are some comparisons of compression size:
Simple SVG (8.8 KiB): With options: 48.1% reduction Without options: 55.5% reduction
Complex SVG (636 KiB): With options: 31.1% reduction Without options: 36.7% reduction
As you can see, adding the options above doesn't have a large effect on compression efficiency. They do, however, allow our SVG files to retain a lot of legitimately useful information.
Ryan Kaldari
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l