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 <[email protected]>
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 <[email protected]>
> 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
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
_______________________________________________
Mobile-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Reply via email to