OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] XML / HTML Transport size

[ Lists Home | Date Index | Thread Index ]

>Better than that, unless I am mistaken the SVG spec *requires* from
>conformant clients that they support gzip compression. While it may seem
>unimportant, this single point is what makes all of Macromedia's
>delirious FUDing about SVG file size moot, as gzip'd SVG documents
>implementing typical Flash examples consistently come out at worst at
>the same size as their Flash counterpart, usually 30% smaller.

You are quite right, I should have checked, allows/requires is a significant
difference - relevant section quoted below. This appears in SVG 1.0, 1.1 and
no modification is suggested for 1.2.

> > Although SVG is a graphics format, it has characteristics that make a
> > .svgz file a lot more interesting than most compressed image formats,
> > through the XML data and the ability to include interactive/executable
> > code.
>And a *lot* more than that! SVG brings joy into the home! It shines and
>it moves! It puts a rose in every cheek!

Indeed it does!!!!!



[[[SVG implementations which support the HTTP protocol must correctly
support gzip-encoded SVG data streams according to the HTTP 1.1
specification [RFC2616]; thus, the client must specify "Accept-Encoding:
gzip" [HTTP-ACCEPT-ENCODING] on its request-header field and then decompress
any gzip-encoded data streams that are downloaded from the server. If the
implementation supports progressive rendering, the implementation should
also support progressive rendering of compressed data streams. ]]]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS