W3C home > Mailing lists > Public > www-svg@w3.org > October 1999

Re: Possible to embed pixmaps in svg files?

From: Chris Lilley <chris@w3.org>
Date: Fri, 15 Oct 1999 17:46:45 +0200
Message-ID: <38074C65.24E0FF93@w3.org>
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...


> (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

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

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.

Received on Friday, 15 October 1999 11:46:58 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:46:47 UTC