Re: SVG and the promise of smaller size

Apu Nahasapeemapetilon wrote:
> 
> One of the benefits of SVG being touted is smaller
> file size when compared to bitmapped formats. But
> in general, SVG files are not necessarily smaller.

In general, they are not necessarily larger either.

> There are many examples on this site:
>   http://indy.cs.concordia.ca/svg/examples/index.html
> The examples are available in GIF as well as SVG
> formats. In most cases the GIF files are smaller!

Could you provide numerical data to back up your claim of "most"? I
agree that the first example in that list is larger as SVG than the
supplied GIF (see below), but I don't see evidence for "most".

Its a nice collection of samples, by the way, and our thanks are due to
Pankaj Kamthan for collecting them together.

> Of course the SVG format has advantages such as
> zoomability, and printing at high resolution. But
> clearly file size is not one of the advantages.

No, clearly file size is not its only advantage, but file size is indeed
an advantage. As with all graphical formats, the answer to "which format
will be the smallest" is "it depends". Depends on the content, depends
on the expectations of the viewer.

> There are instances where SVG files may be smaller.
> For example, if the graphic is large in dimension,
> but only contains a simple circle, the SVG file is
> likely to be smaller than the corresponding GIF.

Yes, in that extreme case the SVG will be miniscule compared to any
raster format. But I hope you don't mean to suggest that all non-trivial
SVG files are going to be larger. That is certainly not the case.

> Promising smaller size will lead to disappointment
> when those promises are not realized. It is important
> to set expectations correctly, or web designers will
> try SVG once and then throw it away.

I hear you, but think that you overstate the case.

Let us look at one of the examples where the SVG is larger than the GIF
- the map of california. That GIF is a thumbnail. You can't read any of
the text, or see closely packed roads well. In a raster-only site,
display of that information would be handled by slicing this image, or
by using a client side imagemap, or otherwise causeing the image to be
divided into areas which would trigger loading a larger scale image of
each area. That is an extra client-server round trip per "zoom" or "pan"
operation.

If the user wanted to see all of the map at that scale, they would need
to download each zoomed section individually (and perhaps stitch them
together). The total downloaded file size would greatly exceed the size
of the SVG. Or the site could just provide a link to  a large image -
but current browsers are often not so good at displaying an image whose
total size is bigger than the screen. I reckon you would need an image
about 2000 pixels high to get that map at a similar level of resolution
to the equivalent SVG.

At the moment, Web sites are focussed on using the current tools. So,
designs make clever use of very small (200x200 or less pixels) images,
often much smaller than that, and carefully ground down in terms of
colors so that the per-pixel data is less. With SVG, designers will be
able to paint with larger, surer strokes, because decent-sized graphics
will no longer be prohibitively expensive in download time. They will be
able to re-use the same graphic at different sizes, on different pages,
without generating a whole series of "foo-large.gif" foo-medium.gif"
images. They will be able to crop images (a standard technique in the
print world). They will be able to re-use portions of images in other
images - symbols, gradients, fill patterns. They will be able to
re-style the same image to iuse it with different colorways in different
places. All of this makes the total byte count of graphics per site much
smaller.

Lastly, remember that SVG is designed to be well compressible using zip
and similar schemes, which HTTP/1.1 can use on the fly. Zip compression
does very little for GIF, JPEG, and PNG images but can have a
considerable effect on SVG - particularly for larger file sizes.

So, I hope you will take a closer look at what "file size" means and not
merely compare low resolution thumbnails to vector graphics originals
without also considering use cases and total downloads.

--
Chris

Received on Friday, 15 October 1999 20:00:29 UTC