Re: Inlined image format
Tony Sanders <sanders@BSDI.COM>
Message-id: <199401261946.NAA01571@austin.BSDI.COM>
X-Authentication-Warning: austin.BSDI.COM: Host localhost didn't use HELO protocol
To: Jonathan Abbey <broccol@arlut.utexas.edu>
Cc: www-talk@www0.cern.ch
Subject: Re: Inlined image format
In-Reply-To: Jonathan Abbey's message of Wed, 26 Jan 1994 13:21:35 CST.
Refer-To: <199401261921.NAA07838@csdsun1.arlut.utexas.edu>
Organization: Berkeley Software Design, Inc.
Date: Wed, 26 Jan 1994 13:46:58 -0600
From: Tony Sanders <sanders@BSDI.COM>
Content-Length: 910
> doesn't strike me as so terribly important. I think that image filters
> can do the job just as well (Mosaic or whatever calls a filter with the
> data and gets back a GIF file, for instance). The important thing is to
> have some kind of standard way to represent any kind of linear transformations
> that such a filter might induce, so that polygonal regions defined as buttons
I agree with you on this point. However, I also believe there is value
in HTML defining a limited set of supported data formats for embedded
image delivery. It is unreasonable to require a user to setup lots of
converters just to read a few documents. Oh, this server uses TIFF, this
server uses JPEG, this server uses... By supporing a single format every
browser that supports <IMG> works correctly, that is a big deal. You start
adding in new types and users will start finding documents they cannot
read.
--sanders