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(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