WebKit+SVG does not handle svgz properly http://www.svgmaker.com/examples.htm has several examples of SVGZ content. Somehow we need to detect that the content is gzip'd and stick a decoder in place to decode it. I'm not sure how we'll do this, perhaps recognize the gzip header...
Another example: http://www.pandimaniacs.com/index.php?mode=svg&lang=en this one uses an object tag...
So my first look at this leads me to believe that this is likely best done down in Foundation in NSURL. NSURL already knows how to decode gzip streams before passing them on to the client, it just would need to be made aware of SVG. However, that's not a very good option for the open source community, so we may need to find some sort of temporary solution until foundation can be enhanced and an updated foundation can be made available.
Created attachment 4300 [details] First pass at svgz support This still seems to have some sort of race condition, which often causes the load to fail. I'm not yet sure why.
Comment on attachment 4300 [details] First pass at svgz support A patch from this weekend.... Basically this hacks the KHTMLPart to try to decode any data in the main resource that looks like gzip. I'm not sure this is the "best" way to do this, but it works, and is a starting point for discussion. There seems to also still be a race condition with the load, wherby sometimes the document parse fails. I'm probably getting an early 0 length write, and should likely be keying my idea of "this is the first write" and thus GZipInflater construction off of something other than the presence or absense of d->m_decoder
Comment on attachment 4300 [details] First pass at svgz support I think this should be done in the decoder, not in the part.
(In reply to comment #5) > (From update of attachment 4300 [details] [edit]) > I think this should be done in the decoder, not in the part. > My concern with making this part of the Decoder had been "inheritance", since Decoders are shared between parts (child parts inherit their parent's Decoders sometimes). I also had concerns about write() calls being passed through the decoder and gunziped unexpectedly. It's possible for me to make the code part of the Decoder class, but not have the execution part of the decode() method... This solution would still require nearly identical changes to KHTMLPart, however instead of creating a GZipInflater object, I would set a bool somewhere, and call "inflate" on the decoder, before passing the inflated string back to the decoder (a second time) for decoding (in decode ()). So given those concerns, would you still like this to be part of Decoder? And if so, would you be OK with it being a separate method "inflate()" on Decoder, or were you suggesting I make this part of "decode()"?
The error is actually on the website, not here. It is not sending the correct Content-Encoding header. See http://wiki.mozilla.org/SVG:MIMEType for info, see http://web.nickshanks.com/safari/tiger.svgz for an example that works fine in Safari. The non gzipped version is at tiger.svg in the same directory. Now another bug is that DrawTest and Safari don't accept gzipped svg documents dragged onto their icons or make them selectable from the open dialog.
I just want to clarify: I recommend NOT 'fixing' this. Safari is a significant browser for people who care about standards (and thus are using SVG). When Safari ships with SVG support, SVG authors will test against it. Because that number is so small at the moment it is best to force them into the correct practice of specifying a Content-Encoding header for gzipped documents. If you do the wrong thing here, by accepting mis‐specified encodings and trying to work around it, you are HURTING the future of the web. Safari in it's current state handles gzipped SVG just fine when the document is sent with the correct HTTP headers. There is nothing that needs fixing.
Darin and I discussed this. WinIE already allows this for the local html case... we think that although it might be a bit "non-standard" it makes sense to support this remote image/svg+xml sent as gzip case. Even if they don't specify the correct ContentEncoding. I'll move my logic into Decoder and resubmit.
Actually, we do handle it "properly". FireFox has made an active choice not to support svgz w/o the correct Content Ecoding header either. There still remains a question about supporting local svgz however.
It's really bad that we don't support local SVGZ files.
This may be automagically supported in Leopard if LaunchServices provides us with proper mime type and fake headers. At least when I last talked to the UTI guy at Apple he seemed to suggest such was possible. I believe this bug has a corresponding Radar which may even be assigned to the launch services team. Adding the "NeedsRadar" keyword for someone to find and associate said Radar.
(In reply to comment #12) > This may be automagically supported in Leopard if LaunchServices provides us > with proper mime type and fake headers. At least when I last talked to the UTI > guy at Apple he seemed to suggest such was possible. I believe this bug has a > corresponding Radar which may even be assigned to the launch services team. > Adding the "NeedsRadar" keyword for someone to find and associate said Radar. Does this work in Leopard now?
It does not. Filed <rdar://problem/5765475>.
(In reply to comment #14) > It does not. Filed <rdar://problem/5765475>. > There is another radar, asking for launch services to send us the headers/mimetype? (not even sure how that would work) correctly when opening an svgz file. It was in the CoreTypes component long ago.
I couldn't find it.
Chromium fixed this. I guess this still needs support from Mac OS X for Safari to work here? Adding a test case.
Created attachment 30925 [details] A test case for LayoutTests
Bugzilla doesn't send the "right" headers for svgz files, so the test fails in bugzilla (and will always fail). It passes on disk for Chromium now, but not Safari. http://code.google.com/p/chromium/issues/detail?id=9936
SVGZ support is still mixed. The issue seems to be that SVGZ files are occasionally passed through XML parsing before sniffing the first bytes. The first bytes should -always- be sniffed. Chromium cross-link: http://code.google.com/p/chromium/issues/detail?id=76968
SVGZ files work fine on the web, when the site is configured correctly: https://jwatt.org/svg/authoring/ SVGZ files could work fine on disk if LaunchServices provided the right information. It's unclear if radar 5765475 has been solved.
(In reply to comment #21) > SVGZ files work fine on the web, when the site is configured correctly: > https://jwatt.org/svg/authoring/ Yes, but the specification dictates mime magic. And this corresponds well with blob and data URIs, do not need to specify the svgz content-type in order to work (per spec). I realize that svgz works well when the content type is specified on a server. If proper mime handling were in place, it'd work in all cases.
It sounds like what you're asking for is content sniffing. .svgz is a file extension which requires the server to be set up correctly. Similarly to serving a .html.gz file and expecting it to render correctly. :) I assume you wouldn't argue that when a server hands us a .html file with something that looks like a gzip header we should try decoding it and rendering it "just in case". :) .svgz files on local disk are a slightly different since there isn't really a server in place to set-up correctly. Which is what this bug is about. On Mac OS X, local .svgz handling should be fixable in the OS.
(In reply to comment #23) > It sounds like what you're asking for is content sniffing. > .svgz files on local disk are a slightly different since there isn't really a server in place to set-up correctly. Which is what this bug is about. On Mac OS X, local .svgz handling should be fixable in the OS. The issue also appears with blob and data uris.