That sounds good for now, but as we talked before, it would be nice to
figure out some way of minifying SVGs in RL in future.
On Wed, Jul 2, 2014 at 12:36 PM, Ryan Kaldari <rkaldari(a)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(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l