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

I've now implemented the gzip-compressed SVG table in fonttools:


https://github.com/behdad/fonttools/commit/612c70dadadbcc85338868ee8a204fadb760a744

On Sat, Oct 25, 2014 at 12:57 AM, Behdad Esfahbod <behdad@google.com> wrote:

> On Tue, Oct 14, 2014 at 8:07 AM, Sairus Patel <sppatel@adobe.com> wrote:
>
>>  Behdad,
>>
>>  This is great. I’m glad everyone’s in agreement.
>>
>>  I’d suggest you bring up this proposal on the OFF list (and, if you
>> like, the OT list), even though they may not be ready to formally move
>> forward with it immediately. This way, the OFF/OT folks will be informed
>> early on on how this part of the spec is evolving.
>>
>
> Just did that.  Lets see how that goes.
>
>
>> And since bumping the (“minor”) version of the SVG table won’t buy us
>> anything, we should leave the version as it is.
>>
>
> Agreed.  As long as the Firefox implementation is happy, we can all work
> around the version number.
>
> b
>
>
>> Thanks!
>>
>>  Sairus
>>
>>
>>   From: <Levantovsky>, Vladimir Levantovsky <
>> Vladimir.Levantovsky@monotype.com>
>> Date: Tuesday, October 14, 2014 at 7:30 AM
>> To: Behdad Esfahbod <behdad@google.com>, Leonard Rosenthol <
>> lrosenth@adobe.com>
>> Cc: Robert O'Callahan <robert@ocallahan.org>, Sairus Patel <
>> sppatel@adobe.com>, "public-svgopentype@w3.org" <
>> public-svgopentype@w3.org>
>> Subject: RE: Compressed SVG? (and a couple of announcements)
>>
>>   As far as the formalities are concerned, we are very late in the ISO
>> process to be able to accommodate the changes like this in the current
>> version of the standard. The 3rd edition OFF document is under final DIS
>> ballot (so the substantial changes can’t be introduced at this time), and
>> to make this change we will need to open a new amendment.
>>
>>
>>
>> As far as timing is concerned, the next MPEG meeting will happen the very
>> next week, so again we are late to introduce a proposal for an amendment,
>> so this can be done at the meeting after next, in Feb 2015.
>>
>>
>>
>> Thank you,
>>
>> Vlad
>>
>>
>>
>>
>>
>> *From:* Behdad Esfahbod [mailto:behdad@google.com <behdad@google.com>]
>> *Sent:* Tuesday, October 14, 2014 1:29 AM
>> *To:* Leonard Rosenthol
>> *Cc:* Robert O'Callahan; Sairus Patel; public-svgopentype@w3.org
>> *Subject:* Re: Compressed SVG? (and a couple of announcements)
>>
>>
>>
>> Ok, great: we have an agreement.
>>
>>
>>
>> Sairus, Robert, please advise how to proceed.
>>
>>
>>
>> Thanks,
>>
>> behdad
>>
>>
>>
>> On Sun, Oct 12, 2014 at 6:29 AM, Leonard Rosenthol <lrosenth@adobe.com>
>> wrote:
>>
>> If you are using gzip and not simple flate – then yes.  But you need to
>> make that VERY clear since most folks will assume that you are not doing
>> that…
>>
>>
>>
>> Leonard
>>
>>
>>
>> *From: *Behdad Esfahbod <behdad@google.com>
>> *Date: *Friday, October 10, 2014 at 2:30 AM
>> *To: *Robert O'Callahan <robert@ocallahan.org>
>> *Cc: *Sairus Patel <sppatel@adobe.com>, "public-svgopentype@w3.org" <
>> public-svgopentype@w3.org>
>> *Subject: *Re: Compressed SVG? (and a couple of announcements)
>> *Resent-From: *"public-svgopentype@w3.org" <public-svgopentype@w3.org>
>> *Resent-Date: *Friday, October 10, 2014 at 2:31 AM
>>
>>
>>
>> On Wed, Oct 8, 2014 at 1:02 PM, Robert O'Callahan <robert@ocallahan.org>
>> wrote:
>>
>> On Tue, Oct 7, 2014 at 11:10 PM, Behdad Esfahbod <behdad@google.com>
>> wrote:
>>
>>   On Tue, Oct 7, 2014 at 10:37 PM, Robert O'Callahan <
>> robert@ocallahan.org> wrote:
>>
>> On Tue, Oct 7, 2014 at 1:36 AM, Behdad Esfahbod <behdad@google.com>
>> wrote:
>>
>>   Robert, Jonathan, are you willing to support this in Firefox?
>>
>>
>>   I'm not sure what exactly your proposal is. As I understand it, you're
>> proposing to allow each SVG document to be optionally, independently
>> compressed via zlib.
>>
>>
>>
>> I was thinking gzip instead of zlib, since gzip-compressed svg is in
>> common use as sgvz.
>>
>>
>>
>>  How does the UA distinguish compressed documents from not-compressed
>> documents?
>>
>>
>>
>> If the data stream starts with 0x1f 0x8b (gzip signature), then process
>> as svgz, otherwise process as svg.
>>
>>
>>
>> That sounds reasonable.
>>
>> The gzip header contains the uncompressed data size.
>>
>>
>>
>> Great point.  Thanks Rob.  The *last* four bytes of the gzip-compressed
>> data is the uncompressed size.
>>
>>
>>
>>
>>
>>   Doesn't that mean concerns about knowing the uncompressed size are
>> already addressed?
>>
>>
>>
>> I hope so.  Sairus, Leonard, does that address your concerns?
>>
>>
>>
>>  Rob
>>
>>
>>
>
>