[6722] in www-talk@info.cern.ch
Re: Overlaying inline images
daemon@ATHENA.MIT.EDU (Chris Lilley, Computer Graphics Un)
Fri Nov 18 10:28:47 1994
Date: Fri, 18 Nov 1994 16:12:22 +0100
Errors-To: listmaster@www0.cern.ch
Reply-To: lilley@v5.cgu.mcc.ac.uk
From: lilley@v5.cgu.mcc.ac.uk (Chris Lilley, Computer Graphics Unit)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Bob Kanefsky wrote, about overlays on images:
> With the current version of HTML,
> that can only be done by having four sets of images (one plain, one with
> contour lines, one with place names, and one with both). If N overlays are
> available instead of just two, it quickly becomes infeasible, requiring 2^N
> sets of images.
Yes
> (In theory the server could run a script to combine them, but
> that isn't feasible here, and it would be very CPU intensive.)
Have you investigated this or are you just making an assumption? Combined with
persistent but not indefinite cacheing, the server load need not be espoecially
great. Using associated alpha for the overlays rather than a separate alpha
channel would also help on the speed front. If you are prepared to forego
anti-aliasing, the image combination becomes trivial: one test and a copy per
pixel.
I agree that it is not a perfect solution, but it is not infeasible unless your
server is running on something like a Windows PC.
> Is there any chance that browsers in the future can be made to accept some
> kind of overlay markup, specifying that two or more transparent GIF images of
> the same size and shape should be displayed one on top of another as one
> inline image?
Let us generalise that away from GIF, and say that we require a means of
registered overlaying of graphics (image or vector or annotation text) with some
means of controlling the compositing.
I can see no particular technical reason why this could not be implemented. The
algorithms are well known. The main problems are :
- designing a positional scheme that does not depend on pixels, essential
once we get vector formats or resizable image formats in there. I see that
the sketch HTML 3 dtd <ftp://ftp.w3.org/pub/www/arena/HTML3.DTD.sketch>
dated Tue Nov 15 13:40:00 1994 has some measurement in em units, but others
are in pixels. I would expect this to be cleared up so ems are usable
throughout. This is needed anyway so that client side hotspots are doable
with vector images like inline CGM, moline, EPS, whatever.
- declaring the positioning of overlapping graphics in the HTML 3 dtd. Perhaps
a table element, without borders, would be of value here.
If the Arena team would care to comment I would appreciate it. This seems to
fulfil a real need that would benefit people in many subject areas.
--
Chris
