Re: Compressed SVG? (and a couple of announcements)

On Fri, Aug 22, 2014 at 7:50 PM, Behdad Esfahbod <behdad@google.com> wrote:

>
>   - Noto Color Emoji SVG sources are not public:
>

Err.  I meant: "are **now** public".



>   https://code.google.com/p/noto/source/browse/#git%2Fcolor_emoji%2Fsvg
>
>   - I put together the country (region) flag SVGs from Public Domain
> Wikimedia Commons into a project:
>
>   https://github.com/behdad/region-flags
>
> Next logical step was to build a Noto Color Emoji SVG+OpenType font, and
> I've been researching that.  Which brings me to the second issue: size
>
> Unfortunately, as opposed to desktop (size not an issue) and web (WOFF is
> compressed), on mobile devices, eg, Android, we really care about font
> size.  So I researched optimizing SVGs a bit, and I've found svgo, which
> seems to be quite impressive:
>
>   https://github.com/svg/svgo
>
> However, no amount of optimization can address the fact that in current
> SVG table, SVGs are stored as plain text.  So I want to suggest that we
> address that by introducing a binary version of the SVG table.
>
> Now, one can argue that this is not a problem as compressing the whole
> fonts or using WOFF is a possibility.  However, in both those schemes, one
> would either need to decompress the whole font / table to get one glyph
> out, or has to keep the decompressed font around (in each process).  Both
> are a non-starter.
>
> So, what I like to propose is to keep the current structure of the SVG
> table, but compress each SVG document independently.  I'm thinking about
> two possible compression schemes:
>
>   - Good old zlib compress2() as used in WOFF, PNG, etc,
>
>   - Some binary XML format.  For me the easiest would be to use the
> Android binary XML.  I haven't tested it yet.  I see EXI is a W3C spec, so
> I researched that a bit.  I find two implementations:
>
>     * http://openexi.sourceforge.net/ (Java and C#)
>     * http://exip.sourceforge.net/ (C)
>
> Unfortunately both seem to be designed by academics / research labs and
> bloated.  I'm guessing that some of this is implied by XML and EXI, but
> some is specific to the implementations.  The exip implementation which
> claims to be small and efficient compiles to a whopping 400kb stripped
> library.  For comparison, here are sizes of three popular libraries on the
> same (64bit) system:
>
>   600kb libfreetype
>   360kb libharfbuzz
>   150kb libpng
>
> That said, I see that the reference WOFF2 encoder/decoder is about 1mb, so
> maybe that's the price one pays.
>
> As far as I understand, exip doesn't even come with a command-line tool to
> encode/decode exi.   I tried the openexi commandline tool, and I'm glad I
> did.  EXI doesn't transform text strings, so bulk of SVGs (paths) don't get
> compressed much other than by the embedded zlib compression in EXI.  I
> tested a few SVGs (large and small), and the gains over just gzip'ing was
> negligible.
>
> I think I'm ready to rule out EXI on the basis of complexity and limited
> gains.  I haven't really looked into Android XML.  I'm guessing that size
> wasn't the primary purpose for designing Android XML.  Perhaps performance
> was.
>
> So, I think I like the zlib compression best.  What do people think?
>
> Cheers,
> behdad
>
>