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

Thanks everyone.  Comments below.

On Sat, Aug 23, 2014 at 6:46 AM, Sairus Patel <sppatel@adobe.com> wrote:

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

I can see arguments on both sides.


> 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).
>

As far as I understand Firefox is the only shipping implementation, so if
we can do things in a compatible way, there should be minimal disruption.
 For example, I think just allowing each SVG blob to be either SVG or SVGZ
is one way to do this.


On Sat, Aug 23, 2014 at 9:39 AM, Jonathan Kew <jfkthame@gmail.com> wrote:

>
>> So, what I like to propose is to keep the current structure of the SVG
>> table, but compress each SVG document independently.
>>
>
> One trade-off to consider here is that it may be desirable to put all the
> glyphs into a single SVG document (or at least put large groups of
> related/similar glyphs into the same document) in order to share common
> components, and to reduce the number of separate SVG documents that need to
> be instantiated by the rendering process.
>
> So using a separate SVG document for each glyph may be convenient in that
> it allows a single glyph to be decompressed independently of the rest of
> the table, but I suspect it'll carry substantial other runtime overheads
> compared to a well-designed multiple-glyphs document.
>

Correct.  But the same argument applies to the uncompressed SVG in that
bundling multiple glyphs in one document can result in significant savings.


On Sat, Aug 23, 2014 at 12:18 PM, Chris Lilley <chris@w3.org> wrote:

> Hello Behdad,
>
> Saturday, August 23, 2014, 7:12:42 AM, you wrote:
>
> > On Sat, Aug 23, 2014 at 12:59 AM, Robert O'Callahan <
> robert@ocallahan.org>wrote:
>
> >> Why don't you just use WOFF?
>
> > Because it's not acceptable that we ship a 1MB WOFF font on Android
> > devices that have to be decompressed to 5MB in every process that wants
> to use smilys.
>
> Where does that 1MB figure come from?
>

The noto/color_emoji/svg directory contains 873 SVG images of emoji.  On
disk as separate files, they take 5MB.  Concatenated together they
take 3711429 bytes.  This is what the uncompressed SVG table will take.
 When tar.gz'ed (which is very similar to what will happen when
WOFF1-compressed), that takes 1146630 bytes.  If I gzip each SVG
separately, they take 1632525 bytes.

Granted, I haven't optimized the SVGs using svgo yet.


On Sat, Aug 23, 2014 at 12:47 PM, Robert O'Callahan <robert@ocallahan.org>
 wrote:

> On Sat, Aug 23, 2014 at 5:12 PM, Behdad Esfahbod <behdad@google.com>
>  wrote:
>
>> On Sat, Aug 23, 2014 at 12:59 AM, Robert O'Callahan <robert@ocallahan.org
>> > wrote:
>>
>>> Why don't you just use WOFF?
>>>
>>
>> Because it's not acceptable that we ship a 1MB WOFF font on Android
>> devices that have to be decompressed to 5MB in every process that wants to
>> use smilys.
>>
>
> Sorry, I wasn't paying attention.
>
> You should be able to share a single decompressed version across all
> processes, right?
>

Theoretically yes, but practically it's very hard to do.  Even if we do, it
will consume many MBs of ram just to keep it there.



> If you put the most frequently used glyphs in their own document at the
> start of the table, you won't have to decompress the rarely used glyphs.
>

Most implementations wouldn't work that way.  They will decompress the blob
as a whole and then look into it.

As a concrete proposal, I like to suggest updating the spec to allow SVGZ
where SVG is currently accepted, with no other changes.  WDYT?

behdad