Re: Enable compression of a blob to .zip file

On 12/3/11 1:16 AM, Julian Reschke wrote:
> On 2011-12-03 01:38, Charles Pritchard wrote:
>> ...
>>> Yes. So is HTML. What's the benefit of compressing SVG first and then
>>> BASE64-encoding it, over having it just URI-escaped, and gzip the
>>> whole HTML page (something most servers will automatically do for you)?
>>
>> SVG is primarily an image format. It's more appropriate to compare SVG
>> and SVGZ to BMP and PNG.
>> SVG files may reasonably be compressed by 80%.
>
> Yes. And they can, using Content-Encoding (and Transfer-Encoding).

Those are HTTP semantics. "SVG implementations that support HTTP must 
support [Content-Encoding and Transfer-Encoding]".
My difficulties are with non-HTTP semantics.
http://www.w3.org/TR/SVG/conform.html

>> SVG files are useful for including inline, in both CSS and JS and HTML,
>> to a lesser extent.
>> My bringing this up is not about HTTP, the HTTP case is already working
>> just fine.
>>
>> It's about all other cases, including Blob uris. Those are not working
>> well at all, and the SVG spec requests that conforming implementations
>> support deflated streams.
>
> Where does it say that?

"SVG implementations must correctly support gzip-encoded [RFC1952] and 
deflate-encoded [RFC1951] data streams, for any content type (including 
SVG, script files, images)."
http://www.w3.org/TR/SVG/conform.html

That interpretation, though, doesn't apply as cleanly to my argument as 
I'd hoped.


>
>>>> There's been a 9 years of lingering bug reports area:
>>>>
>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=157514
>>>> https://bugs.webkit.org/show_bug.cgi?id=5246
>>>> http://www.ietf.org/mail-archive/web/pkix/current/msg27507.html
>>>> http://lists.w3.org/Archives/Public/www-svg/2011May/0128.html
>>>> http://code.google.com/p/chromium/issues/detail?id=76968
>>>
>>> Indeed. It seems that except Opera all browsers do this right.
>>>
>>> Again: it can be done, but it should be done correctly.
>>>
>>> Defining a separate media type is the simplest thing to do here.
>>
>> Image formats have sniffing specified within the HTML5 specs. Even HTML
>> has some sniffing. It seems completely reasonable that SVG be included
>> in this.
>>
>> Adding a separate media type would work, but it's counter to what
>> current specifications call for. It's also unnecessary for the HTTP
>> protocol.
>
> We had a very long discussion about the svg+xml registration, because 
> it was a bit vague on compressed SVG. The IETF rightfully (IMHO) 
> insisted on removing the vagueness, because the base spec for +xml 
> (RFC 3023) doesn't allow compression.

Thank you very much for this information.

> If it turns out that svgz as a media format *is* needed, then we 
> should define a type for it.

Given that Blob has only one mechanism, mime types, and the IETF has 
rejected any possibility of +xml having compression, I'm going to back 
off the idea of sniffing the +xml mime type.

If there were a mime type that were more appropriate for 
compressed/non-compressed use, would it simply be:  "image/svg" ?

-Charles

Received on Saturday, 3 December 2011 18:43:51 UTC