- From: Chris Lilley <chris@w3.org>
- Date: Fri, 15 Oct 1999 17:46:45 +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: > > "This allows you to embed a PNG or JPEG (but not a > > GIF) image within an SVG image. Note that you use > > the xlink:href attribute rather than the HTML img src > > attribute to point to the image file. Also note that you > > can specify the precise location of the embedded > > image within the SVG image." > > note that they say "embed in image", not "embed in file". > > I suppose that what they're trying to say is simply that > the "image" element is used to draw raster images... Right. > (is the GIF restriction correct, btw?) " Conforming SVG viewers need to support at least PNG, JPEG and SVG format files. " SVG Spec 6th draft, section 3.7, 12 August 1999 Consider if all Mac browsers only understood PICT and all Windowes browsers only understood BMP - that would be a mess. HTML does not constrain what image formatss can be used [1] although HTML profiles can require certain formats to be supported. As it turns out, there are some formats that are in common use but that is more luck than design. The first HTML browser could only display encapsulated PostScript images - and not in the same window as text - while the first HTMLK browser to display images inline supported XBM files, GIF, and HDF (which is a gnarly, scientific visualisation format). We can require JPEG because there is a freely available library, its widely implemented, there are no patent restrictions on the parts of the JPEG standard that are actually used. We can require PNG for similar reasons - freely available libraries (notice that Java 1.3 adds native PNG support due to popular demand, though there have been libraries available for older versions), wide implementation support, no patent restrictions. We can require both of these, rather than just one, because there is some content such as photographic imagery which is much better suited to JPEG and there is other content such as line art, screenshots, computer generated imagery which is much better suited to PNG, and then there is content where you trade off quality against size and pick one or the other. And we can require SVG support in SVG implementations, clearly ;-) Note that an SVG image, embedded as an image inan other SVG file, is a separate rendering tree with its own DOM, its own stylesheet information, etc. We could have added GIF as a required format, but chose not to because then all implenmentations - both viewers and generators - would be subject to Unisys license fees and all Website owners would also be subject to fees for all content not produced by licensed programs. We could have made GIF "recommended but not required" but then that gives an interoperability headache. The spec does not require other formats to be supported. They can be, but then your content is not guaranteed to work in all conformant implementations. And right from the launch of SVG when the spec gets finalised, we expect all implementatiosn to be conformant or to be moving rapidly to conformance. Because basically, there are a lot more users and graphic designers than there are implamenters and implementations, and by settinga high standard for implementations we reduce the huge financial and time penalty that current Web designers incur when designing content for existing HTML browsers, which costs the industry in total an astonishing amount. -- Chris
Received on Friday, 15 October 1999 11:46:58 UTC