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

I'll check out these links, Behdad, but for now:

The Adobe proposal before we merged with Mozilla's, did have zlib compress2(): see the attachment to http://lists.w3.org/Archives/Public/public-svgopentype/2012Aug/0000.html.

It required the SVG doc to always be compressed. The thinking was that if compression was to be allowed, impls would need to implement it, and so the table should always just always require it, to simplify things (production, impls, testing). I believe the Mozilla folks weren't too keen on compression. I think the argument was it would require a buffer to decompress the SVG docs into, as opposed to rendering from the (possibly memory mapped) SVG table in the font directly. So it didn't make it into the merged proposal.

The issue is, if we now introduce an option to compress, that's a "major version number" change to the SVG table, right, since such a font won't work with implementations of the current spec? In other words, we're talking about an 'SVG2' table - unless we think it's OK if such a font doesn't work with, or is rejected by, impls of the current spec (we don't usually do that kind of breaking change in OT).

However, if compression is something the community is behind at this point, we can think of a way to fit it in in the least disruptive manner.

Sairus

From: Behdad Esfahbod <behdad@google.com<mailto:behdad@google.com>>
Date: Friday, August 22, 2014 at 5:37 PM
To: "public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>" <public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>>
Subject: Re: Compressed SVG? (and a couple of announcements)
Resent-From: "public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>" <public-svgopentype@w3.org<mailto:public-svgopentype@w3.org>>
Resent-Date: Friday, August 22, 2014 at 5:38 PM

On Fri, Aug 22, 2014 at 7:50 PM, Behdad Esfahbod <behdad@google.com<mailto: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