Re: was: gif or jpg

At 15:22 24/12/97 -0500, Kevin Dail wrote:
>Which is likely to work out better(compatability, download). 
>Four seperate graphics, each 75X50 pixels, or an image map made
>of those 4 put together at 75X200? I want to use them as buttons for links.

A single graphic is likely to be smaller; better compression and one rather
than four sets of graphics file overhead.  Since the graphics are typically
similar in characteristic, they might easily benefit from things such as
largely overlapping compression dictionaries.

But most notable is that only a single file download (rather than four)
would be required. This reduces network overhead, as well as eliminating a
considerable amount of latency (at least one round-trip time per file).
Such will be the case, unless (still uncommon) _both_ ends are fully
deployed with HTTP 1.1 protocol.

[Note that the overheads mentioned in the two proceeding paragraphs are
distinct, hence the effect is cumulative.]

True, as some have suggested, there are situations where the graphics are
quite different in character, that they'll benefit from compression
methodologies and/or dictionaries. I'm doubtful, however, that such will be
typical.

The one predictable disadvantage of a single graphics is that client-side
image mapping is less widely deployed, and some of the implementations are
broken (mostly partial implementation). The fall-back however is easy,
either server-side includes as well, or a page with links to the several
choices. I'd expect in most situations one of these would work quite nicely.

The ideal is likely a PNG graphic, with client-side image map, and a backup
text link page for those browsers which don't support client-side image
maps (or PNG graphics). But, of course, your mileage may vary. <g>

/Harold

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Harold A. Driscoll                       mailto:harold(at)driscoll.chi.il.us
#include <std/disclaimer>      http://homepage.interaccess.com/~driscoll/

HWG: hwg-graphics mailing list archives, maintained by Webmasters @ IWA