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