- From: Chris Lilley <chris@w3.org>
- Date: Thu, 14 Oct 1999 13:49:01 +0200
- To: Fredrik Lundh <fredrik@pythonware.com>
- CC: www-svg@w3.org, Jan Aarsaether <jaa@metis.no>
Fredrik Lundh wrote: > > Jan Aarsaether <jaa@metis.no> wrote: > > I just joined this list. I've looked at the log of this list, but > > could not find any answer to my question. > > iirc, this has been discussed before, and at least > at that time, the W3C response was "forget it"... > > (by some reason, the extra 33% that base64- > encoding adds seems to be a showstopper to > some...) That and the increase in cache pollution with multiple, non-reusable copies of images. > > If so, could anybody direct me to some documentation on this or even > > better, some examples? If not, it would be helpful if somebody could > > verify that this is a (current) limitation in svg and perhaps inform > > me of any future plans to implement include such functionality. > > 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. > on the other hand, several major players in the > graphics applications arena has announced that > they'll support SVG in a near future. could be > interesting to learn how they are addressing > this little problem... > > (and maybe chris's time machine is still working. > the last time I brought something up, it was al- > ready in the spec! ;-) Not in this instance. However, some possibilities for acheiving "all in one file": a) lobby implementers to support the data: URL type b) zip a directory containing the SVG, any external stylesheets, and any required raster images -- Chris
Received on Thursday, 14 October 1999 07:49:10 UTC