Embedded graphics (was Re: Book metaphor)
Bob Wildfong <bobw@csg.uwaterloo.ca>
From: Bob Wildfong <bobw@csg.uwaterloo.ca>
Message-id: <9211231511.AA20554@csg.uwaterloo.ca>
Subject: Embedded graphics (was Re: Book metaphor)
To: dsr@hplb.hpl.hp.com (Dave_Raggett)
Date: Mon, 23 Nov 92 10:11:56 EST
Cc: www-talk@nxoc01.cern.ch
In-reply-to: <9211231123.AA12237@manuel.hpl.hp.com>; from "Dave_Raggett" at Nov 23, 92 11:23 am
X-Mailer: ELM [version 2.3 PL11]
>
> Pictures
> ========
> It seems sensible to support a variety of formats: TIFF, GIFF, DIBs
> Fax group III/IV, CGM etc. The idea of embedded objects which return their
> size and can display themselves at a given location seems appropriate.
>
> The client doesn't know in advance about these embedded objects, it therefore
> makes sense for the server to be able to append them to the requested html
> document so as to avoid a further network loop delay for retrieving them.
>
> Dave Raggett
>
> HP Labs, Bristol, UK. (dsr@hplb.hpl.hp.com) +44 272 228046
I've been through this line of thought in a hypertext/electronic book project.
Yes, it's more efficient to include the graphics in the HTML data stream, but
only if you just have one version (format) for each graphic.
We found it best in the long run to provide our embedded graphics in several
formats, and allow the client to choose the format most appropriate for its
output device (e.g. 8-bit vs 24-bit colour, Postscript if the device supports
it, WMF if the client is running the Microsoft Windows version of the viewer
program, etc).
The server sends a list of available formats and the client requests the
graphic file that it prefers. This permits the best available graphic quality
on each of several possible output devices, but imposes an extra network delay.
Still, graphic files tend to be pretty big, so the extra delay is only a few
% of the file's download time.
Bob Wildfong bobw@csg.uwaterloo.ca
Waterloo, Ontario bobw@csg.waterloo.edu
#include <stddisclaimer.h>