[mpeg-OTspec] SVGZ in SVG+OpenType

[Behdad Esfahbod]

Thanks Chris,

On 14-10-26 05:07 PM, Chris Lilley chris at w3.org [mpeg-OTspec] wrote:
>  
> 
> Hello Behdad,
> 
> Saturday, October 25, 2014, 9:56:18 AM, you wrote:
> 
>> Allow gzip-compressed SVG documents where SVG documents are currently
>> accepted.
> 
> This is a useful clarification. I say clarification because a
> conforming SVG viewer is already required to accept gzip-compressed
> content:
> 
> SVG implementations must correctly support gzip-encoded [RFC1952]
> and deflate-encoded [RFC1951] data streams, for any content type
> (including SVG, script files, images).

Right.  You mentioned this before, and I tried to confirm it, but got confused
and thought the requirements only affect HTTP transport.  I checked again now
and see your point.

This distinction is important though, because if your reasoning is to be
followed, then deflate-encoded SVG must also be supported.

However, from the point of view of SVG+OpenType specification / working group,
they may not feel bound by the SVG viewer conformance requirements.

Anyway, I think you know better what the implications are one way or another.
 In the mean time I'll go build a font, such that Jonathan can take a look at
implementing it in Firefox.

behdad

> SVG implementations that support HTTP must support these encodings
> according to the HTTP 1.1 specification [RFC2616]; in particular,
> the client must specify with an "Accept-Encoding:" request header
> [HTTP-ACCEPT-ENCODING] those encodings that it accepts, including at
> minimum gzip and deflate, and then decompress any gzip-encoded and
> deflate-encoded data streams that are downloaded from the server.
> When an SVG viewer retrieves compressed content (e.g., an .svgz
> file) over HTTP, if the "Content-Encoding" and "Transfer-Encoding"
> response headers are missing or specify a value that does not match
> the compression method that has been applied to the content, then
> the SVG viewer must not render the content and must treat the
> document as being in error.
> 
> http://www.w3.org/TR/SVG11/conform.html#ConformingSVGViewers
> 
>> As there are only one current implementations and the format is backwards
>> compatible, it was recommended on the mailing list by Sairus to keep the table
>> version number to the current number.
> 
> Yes, I think that makes sense; because arguably implementations should
> have accepted this from the start. If they did not, they were
> non-conforming.
> 
> -- 
> Best regards,
> Chris Lilley, Technical Director, W3C Interaction Domain
> 
> 

-- 
behdad
http://behdad.org/