[
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!!!!!
Cheers,
Danny.
from
http://www.w3.org/TR/SVG/conform.html#ConformingSVGViewers
[[[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. ]]]
|
