- From: Chris Lilley <chris@w3.org>
- Date: Thu, 14 Oct 1999 14:56:21 +0200
- To: Fredrik Lundh <fredrik@pythonware.com>
- CC: www-svg@w3.org
Fredrik Lundh wrote: > > Chris wrote: > > That and the increase in cache pollution with multiple, non-reusable > > copies of images. > > CSS leaves that to the information providers. I still > don't see why SVG cannot do the same (mechanisms, > not policy, remember?). Well, I gave two mechanisms below. > > > I sometimes think the main idea behing SVG is to > > > ship things over a network, not to store it on a > > > local disk (things like DICOM comes to mind...). > > > > That being why it is being developed at W3C <smile> but on the other > > hand, I do have a bunch of SVG on my local disks that seems to work > > fine. > > oh, sure. after all, things are a bit better than > pre-3.0 DICOM, since all parts of a multifile SVG > have well-defined file formats :-) ;-) > > Not in this instance. However, some possibilities for acheiving "all in > > one file": > > > > a) lobby implementers to support the data: URL type > > is this a spec that I've missed? Quite possibly. I'm pushed for time to find the RFC right now (I am supposed to be doing something else) but IIRC its referenced from the "file upload" HTML extension RFC. Basically, some encoded version of the data, in the URL, is the data. > > b) zip a directory containing the SVG, any external stylesheets, > > and any required raster images > > only works if all the major SVG tool providers > implement this. will they? Ask them. But note that SVG was defined to compress well using zip, since HTTP/1.1 can use zip compression as a content transfer encoding. And note that any SVG implementation is likelyto have zlib (or equivalent functionality) linked in anyway to support PNG images, so code bloat is minimal. -- Chris
Received on Thursday, 14 October 1999 08:56:34 UTC