Overlaying inline images

Bob Kanefsky ([email protected])
Tue, 22 Nov 94 02:45:10 PST


OK, I'll concede that I don't know for sure that combining images on the fly
is too CPU intensive. I haven't tried it. We have some administrative
barriers that make it difficult to develop WWW scripts, especially if they're
not written in Perl. That's our problem and doesn't justify a new feature of
HTML, but it does make me less inclined to try something I expect will turn
out to be unworkable. Anyway, I think I'm justified in wanting a priori to
keep the requirements for the server as lightweight as possible: WWW use in
general is heavy and growing explosively, and Mars seems to be very popular,
judging from the hundreds of thousands of accesses by more than 10,000
distinct hosts over the last four months.

Let me try to make my case better by proposing two applications that would be
difficult to do without overlay support in HTML, for reasons other than CPU
load on the server.

1. The images might not be on the same server. Someone might want to import
an image produced by specialized code on another server, and then annotate it.
For example, it would be nice to import a map from the map viewer at PARC and
add specialized overlays (e.g., shuttle image locations, an airline's routes,
a telephone network's trunk lines, the route to your building). Without an
overlay feature, this requires either getting a duplicate of the large
database the map viewer uses and duplicating much of the software, or having
an HTTP client and GIF file parser built into the server. (If the first
option doesn't seem so unworkable, suppose that the background is the current
weather map or traffic congestion map instead. Maybe you want to show the
\quick/ route to your building or explain why half your flights are late.)
The client-within-server option is possible, but it seems an unnecessary
implementation burden for each server, and it doubles the network traffic.

2. If HTML supported overlaying small (opaque) images over large images at a
specified position, it would make some nice interfaces possible that would
otherwise require retransmitting unnecessarily large amounts of data over the
network. The big image can put the small one in context. E.g. it might be an
unchanging picture of a clickable panel of control buttons, with a "screen" in
the middle that contains a changing picture. Or it might be a global map with
a magnifying glass under which a detail is displayed at 10x scale.

The big image may take 30 seconds to download, but after that the user can
move to dozens of different views with a fast response time, because only
the small image is being downloaded.

The syntax might look something like this, as a strawman (or is that
"cohesively-challenged-person"?) proposal:

<Overlay IsMap>
<Image width=1000 height=1000 src="Big-Map.gif">
<Image width=120 height=120 src="Magnifying-glass-Stencil.gif"
x-offset=290 y-offset=590
TRANSPARENT>
<Image width=100 height=100 src="Closeup-of-20S-45W.gif"
x-offset=300 y-offset=600
OPAQUE>
</Overlay>