Compressed SVG? (and a couple of announcements)

Hi,

First, a couple of announcements, for people interesting in building SVG
fonts:

  - Noto Color Emoji SVG sources are not 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