Post by gialloporporahttp://www.gialloporpora.netsons.org/images/ff64.svgz
a me funziona. Secondo me è il server configurato male, devi essere
sicuro di due cose: 1) che sia definito il mime type dei file svgz
come image/svg+xml 2) che per svgz sia inviato l'header che indica a
Firefox che è compresso
AddType image/svg+xml svgz
AddEncoding gzip svgz
Altre prove. Sto seguendo la tua traccia e fin'ora sembra funzionare.
Post by gialloporporaRealising this has drifted a little off topic, but wanting to clear
Phillip, SVG is Scalable Vector Graphics
http://www.w3.org/Graphics/SVG/ http://www.w3.org/TR/SVG11/ the
data: protocol is defined by RFC 2397 'The "data" URL scheme', L.
Masinter, August 1998.
Boris, the fact that compressed SVG and uncompressed SVG have the
same Internet media type is by design, and follows the relevant IETF
guidelines on separating content type from compression. See
http://www.w3.org/TR/SVGMobile12/conform.html#ConformingSVGServers
for a discussion on Internet media Type and compression. It would be
incorrect and inappropriate to register all combinations of media
type times compression method as new media types.
Jonathan, you are correct that the data: protocol does not provide a
means to indicate the Content-Encoding (or indeed, any other http
headers). I would therefore not recommend using compressed data in a
data: uri since there is no way to indicate that it is compressed or
what method has been used to compress it.
All, the general issue is that most protocols (file, ftp, data, etc)
do not provide metadata headers - just the actual data. Internet
Media type, compression, language, and so forth therefore need to
infer this information.
For SVG, the .svg extension implies media type image/svg+xml while
the .svgz extension implies media type image/svg+xml and
Content-Encoding: gzip.
"SVG implementations must correctly support gzip-encoded [RFC1952]
and deflate-encoded [RFC1951] data streams, for any content type
(including SVG, script files, images)." [1]
As Chris as well mentioned (in comment 56), this must be done using
heuristics due to lack of meta-information in several protocols.
Although the currently available test suite [2] doesn't explicitly
test for this, there's a specific test [3] in SVG 1.1 SE which will
break whenever the test suite is being executed locally (the online
version works file due to the metadata inserted at HTTP level).
<rant> Apart from the conformance issue, this is one of the most
longstanding and annoying and issues regarding SVG support. The
broken feeling when opening ".svgz" files locally probably causes
many users not to use a format which is highly desirable due to the
XML overhead, for perceived performance and bandwidth reduction
reasons. Also, the behavior is quite unintuitive/unexpected for most
users/authors, as they are able to access the exact same content
online, but not locally... :-| </rant>
Post by gialloporporaand there is only one MIME type for svg.
This is the real problem. Or lack of content-encoding in data:, I
guess. But plenty of other things don't support content-encoding.
la compressione.
e FF ha un solo tipo di immagine le svg (le svgz non sono un tipo distinto).
specificabile solo lato server e non tramite il caricamento da locale.
e funziona. Potete provare con IE e altri browser?