[mpeg-OTspec] SVGZ in SVG+OpenType

[Chris Lilley]

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

  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